> ensure that
> the notification process leaves a clear indicator that a notification
> occurred.
As David and I agreed off-list, this is not a problem. There is always
some way (whether using locks or atomic operations) to ensure that an
interrupted thread correctly sees that the notification has already
occurred. In fact, I was assuming this to be the case, and should have
phrased it more clearly to begin with. Restating it, changing line (X):
S W
... ...
Block in monitor-wait queue
Choose W from monitor-wait queue
Wake up
Notice you are interrupted or timed-out
Transfer record of W to lock queue
Notice you are already on lock queue(X)
Block waiting for lock
And from an implementor's point of view, the main issue remains, what
to do when thread S makes a mistake by transfering W to lock queue
even though W is, unbeknownst to S, interrupted or timed out. The spec
must say enough (but not too much!) so that implementors can easily
tell whether they've done the right thing here, and programmers can
depend on it.
While the above race is extremely rare, the course of action taken
here will generally also apply to the easily observable case where
thread S definitely did not make a mistake:
S W
... ...
Block in monitor-wait queue
Choose W from monitor-wait queue
Transfer record of W to lock queue [W is NOT now interrupted or timed out]
Wake up
Notice you are interrupted or timed-out
Notice you are already on lock queue
Block waiting for lock
This is the case Bill's test program tests.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT