You have MPI_WINDOW_LOCK (a blocking lock acquisition call)
You have an MPI_WINDOW_TRYLOCK which returns true or false (as the
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.
BBN UK Ltd
Phone : +44 117 9071438