Yes, you do -- so my notes (a) and (b) below are only for the "if lockall is only for shared locks" case. On 05/26/2010 11:00 AM, Underwood, Keith D wrote:
I thought you had to assert that there were no exclusive locks anywhere for the shared lock to be a no-op... Now, we may want that requirement, but I think we have to state it if we do. I.e. What if somebody uses lock to get an exclusive lock?
----- Original Message ----- From: [email protected] <[email protected]> To: MPI 3.0 Remote Memory Access working group <[email protected]> Sent: Wed May 26 08:46:59 2010 Subject: Re: [Mpi3-rma] RMA proposal 1 update
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.
With respect to (2) -- I'm OK with keeping this only for shared locks, but note that:
(a) if we allow this only for shared locks, it's going to be a no-op for all architectures (cache coherent and non-cache coherent).
(b) It's still useful to have in order to be consistent with the user's expectation -- that is, once a lockall(SHARED) is done, the user cannot do a LOCK(EXCLUSIVE) for example. If we remove this call, the user's expectations will break.
Another way to look at this is, to make a "LOCKALL" a fourth form of synchronization (a new one), rather than an extension to the LOCK/UNLOCK synchronization.
-- Pavan
On 05/26/2010 10:36 AM, Rajeev Thakur wrote:
Perhaps we should allow only shared locks with lockall.
Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Underwood, Keith D Sent: Wednesday, May 26, 2010 8:59 AM To: MPI 3.0 Remote Memory Access working group Cc: [email protected]; [email protected] Subject: Re: [Mpi3-rma] RMA proposal 1 update
Interesting. We shouldn't lose sight of the fact that lockall/unlockall when you get an exclusive lock or even when you don't assert that nobody else has an exclusive lock will be... complicated. The advantage of lockall/unlockall is that there are usage models where it is ok to not take an exclusive lock and to assert that nobody will.
Keith
-----Original Message----- From: [email protected] [mailto:mpi3-rma- [email protected]] On Behalf Of William Gropp Sent: Wednesday, May 26, 2010 7:07 AM To: MPI 3.0 Remote Memory Access working group Cc: [email protected]; [email protected] Subject: Re: [Mpi3-rma] RMA proposal 1 update
I don't think we talked about it at all - the single lock restriction was simply the consequence of needing a way to define the scope of passive target operations and support non-cache-coherent systems (don't forget that "lock" isn't a "lock" - its a "begin access epoch"). Bill
On May 25, 2010, at 11:28 PM, Torsten Hoefler wrote:
On Tue, May 25, 2010 at 10:04:41PM -0600, Underwood, Keith D wrote:
Lockall/unlockall was definitely on the list at the last meeting. There wasn't consensus on many things, but there was on that one ;-) Ok, I added it. See wiki.
We should still discuss this further. It seems like we're adding much functionality and I'm not 100% sure if this is all compatible with the MPI-2.0 design. Does anybody know the rationale for the one-lock restriction in MPI-2?
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 _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
-- Pavan Balaji http://www.mcs.anl.gov/~balaji