Marc,
You have MPI_WINDOW_LOCK (a blocking lock acquisition call)
You have an MPI_WINDOW_TRYLOCK which returns true or false (as the
current MPI_IPROBE).
Don't you also want an MPI_WINDOW_ILOCK which returns a request which
one can later test or wait on ?
The request completes once the lock is claimed by this call. Such a
call would allow non-busy waiting for a lock, which is not possible
with the current calls.
Of course this may have implementation implications (like requiring a
global queue of lock requests somewhere.)
****
a global queue might be needed, anyhow, for the blocking lock call, if we want
to be able to deschedule the blocked process.
****
Also you say nothing about fairness of lock acquisition. (This may be
deliberate :-) ). Somwehere I think we should say something, even if
it is only that no fairness guarantees are given.
****
Fairness is probably important. Thinking is needed, in a multikernel
environmnet, on the interaction between global scheduling, as implied by lock
acquistion/release, and local schduling decisions by the local kernel. E.g.,
the priority inversion problem, but now due global locks.
****
-- Jim
James Cownie
BBN UK Ltd
Phone : +44 117 9071438
E-Mail: jcownie@bbn.com