You missed the connection to the bottom half of the posting! :-) This
was the preamble meant to show that a big fragment (the most prevalent)
of the 1-sided functionality works nicely without requiring support for
the third-(uninvolved)-party scenario (A puts in C, B gets from C, C
doesn't participate). Yes, this leaves locks in the "strict" model
requiring it. That's where I introduce the flexibility of allowing
implementations to use the relaxed-model for locks (attribute key).
Greg doesn't like this duality and I understand his position. I prefer
sticking to the relaxed-model only, I was just trying to accomodate a
few users and vendors who want to force a shared memory programming
model (3rd party scenario) inside a message passing standard. I happen
to disagree with this (in spite of being a shared memory vendor) and
think it's a bad step for MPI. We can all get together, form the SMI
Forum and start hacking on that independently. But MPI is the current
"moving train" in which this stuff is being tossed, so I'm willing to
let these vendors deliver the strict-locks model to these users, without
mandating it on all implementations.
This doesn't force all users to code "if (impl-a) ... else ...".
In fact, most users will just use the barrier model and not have to
worry about this. Others may use locks but no need the 3rd-party
scenario (the window owner is either the producer or the consumer).
Only the subset of users that want to use the locks _and_ need the
3rd-party scenario _and_ want to be portable to low quality
implementations _and_ still be super-fast on high quality ones
_then_ they would have to use the attribute key and do if/else.
Likewise for the generalized requests and threads... but that's to be
discussed in mpi-ext.
--Raja
-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division