Doug Lea wrote:
> 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.
I think there are two issues to cover:
a) the order of events
Given that a thread does: t.interrupt(); o.notify(); is there any
guarantee about the order of those events from t's perspective?
I think the answer must be no. In terms of the semantics of wait()
when a thread is disabled for scheduling purposes one of four events
will cause that thread to become reenabled for scheduling after it has
acquired the monitor lock. Those four events are: notification,
interruption, time-out or spurious wakeup. If more than one event
occurs there is a race as to which event will actually "wakeup" the
thread. The winner of that race determines the "reason" the wait()
completed. There is no requirement that interrupt() or notify()
synchronously and atomically take t to the finish line of the race,
hence t may see the outcome of the race differently. For example,
interrupt may just signal the thread such that when it is next
scheduled it will reacquire the lock; meanwhile notify might
synchronously move a thread from the wait-set to the lock-queue
without actually waking it.
Given the above I think it reasonable that an implementation be
allowed to change the "reason" for the wait returning, to give
preference to being a cancelation point for example, provided it
doesn't conflict with b) below.
b) lost notifications
Can a thread t that was logically the recipient of a notification
return from wait() other than normally? And if so, is another thread
that was waiting at the time t was selected, guaranteed to return from
wait()?
I think the answer in both cases is yes. If t consumes a notification
but prefers to respond to interruption then it may do so, but it must
pass the notification along. And as has been discussed, the only way
to do this correctly is to actually issue a notifyAll().
Now I've said that I'm not sure it really adds anything to what's been
said before. Oh well :(
David Holmes
-------------------------------
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