[Mpi3-rma] RMA proposal 1 update

Torsten Hoefler htor at illinois.edu
Wed May 26 13:01:06 CDT 2010

On Wed, May 26, 2010 at 11:40:14AM -0500, 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.
I believe this would just be da-facto illegal in the current set of
rules. Because lock-all gives you a shared lock. If anybody is trying to
acquire an exclusive lock, he would deadlock. 

> > 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.
Yes, but that's the same with MPI_Send, i.e., the user has to assume
that the program might block.

All the Best,

 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Research Associate
Blue Waters Directorate | University of Illinois
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736

More information about the mpiwg-rma mailing list