[Mpi3-rma] RMA proposal 1 update
Rajeev Thakur
thakur at mcs.anl.gov
Wed May 26 12:36:15 CDT 2010
Implementation wise, allowing nested locks (with exclusive) may not be a
trivial change.
Rajeev
> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org
> [mailto:mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of
> Pavan Balaji
> Sent: Wednesday, May 26, 2010 11:52 AM
> To: MPI 3.0 Remote Memory Access working group
> Subject: Re: [Mpi3-rma] RMA proposal 1 update
>
>
> On 05/26/2010 11:40 AM, Rajeev Thakur wrote:
> >> Yes, you do -- so my notes (a) and (b) below are only for the "if
> >> lockall is only for shared locks" case.
> >
> > Not just lockall. The user would have to assert that no
> other process
> > will call regular lock with an exclusive lock.
>
> Correct. But if it's a different synchronization primitive, we don't
> have to care about that case.
>
> >> I think there are two parts here -- (1) to remove the
> restriction on
> >> whether only one lock can be acquired; and (2) to provide
> the lockall
> >> convenience function.
> >>
> >> (1) is a minor change to the standard and should be included.
> >
> > If you allow nested locks with exclusive locks, the user code may
> > deadlock depending on what the implementatation chooses to
> do: block on
> > a lock or defer everything until unlock. The user code may
> work in some
> > cases, and may not work in other cases.
>
> That's a user error, and is to be dealt by other tools outside of the
> scope of MPI.
>
> There are a lot of ways a user can screw up even within the
> current MPI
> standard. We can't drop flexibility because someone might screw up.
>
> -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
More information about the mpiwg-rma
mailing list