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