[Mpi3-rma] RMA proposal 1 update

[Rajeev Thakur]

One difference between a lockall and multiple nested locks is that
lockall takes a single lock type for the entire set. With multiple
nested locks, the user could make a thousand calls to Win_lock, with
arbitrary shared and exclusive locks, and the implementation would have
to keep track of the thousand lock states.

Rajeev
 


> -----Original Message-----
> From: Rajeev Thakur [mailto:thakur at mcs.anl.gov] 
> Sent: Wednesday, May 26, 2010 12:36 PM
> To: 'MPI 3.0 Remote Memory Access working group'
> Subject: RE: [Mpi3-rma] RMA proposal 1 update
> 
> 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
> > 
>