On Mon, Dec 26, 2011 at 10:36:28PM -0600, Pavan Balaji wrote:

On 12/26/2011 10:31 PM, Torsten Hoefler wrote:

...

...

Also, the case I had in mind was using lock/unlock. If it is valid for the user to do a for loop of Win_lock(exclusive), I'm not sure how we are taking away the MPI implementation burden by not allowing Win_lock_all(exclusive). A for loop is a silly user program, having a slow P^2 lock_all exclusive (in the extreme case) is a problem in the MPI lib.

True. Hence the need for a lock_all(EXCLUSIVE). But if that's not provided, there should at least be a fall back option, and the for loop is that.

Besides, silly or not, it's a valid MPI program and the MPI implementation has to deal with it.

No, the MPI library does not have to deal with silly use programs. If a user decides to write a non-scalable program, then the MPI library cannot do much.

...

...

More importantly -- even if we want to not allow exclusive locks in WIN_LOCK_ALL, I would suggest retaining the lock_type parameter and say that the behavior of EXCLUSIVE locks is undefined, so that it's future proof in case we want to add it later. Also, implementations that want to provide it can do so without random hacks or new API functions. Yes, I thought about this, however, our original #270 didn't have this feature and I decided to revert to the original. We can do a straw vote here and fix it quickly. I have no strong opinion.

I'd prefer a straw vote on this. I don't see any additional burden on implementors who don't want to allow it. But it's much cleaner for implementations that decide to allow it.

...

...

The idea is that a process gets a lock on a shared memory region and uses it for remote RMA communication. Yes, that should work but the semantics of overlapping windows are hairy.

I think they are quite well defined, and fairly intuitive once you think through it. But that's just personal opinion. I agree, but I fear that 98% of our user-base (the people who did not spent dozens of hours discussing the semantics :-) ) may think differently (remember that there was a large and credible group in the Forum that wanted to completely abandon those semantics just two years ago :-) ).

All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- "All that we need to make us really happy is something to be enthusiastic about." -- Charles Kingsley