[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,
Torsten
--
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