At 9:05 AM -0400 8/6/03, Doug Lea wrote:
>Part of the problem here is that we still have trouble saying exactly
>where the contoversy lies. Here's a stab at it, but I suspect that
>even this folmulation itself may be controversial.
>
>I see this as two distinct issues.
>
>A. When one thread, t, does a wait -- for completeness, assume a timed wait,
> mon.wait(msecs)
>there is in intrinsic race among the following ways for the wait to return:
>
> 1. Some thread invokes mon.notify, and thread t was chosen
> 2. Some thread invokes mon.notifyAll
> 3. Some thread invokes t.interrupt
> 4. The wait times out
> 5. The wait spuriously returns
>
>The choices for governing this are:
> A1. Must an implementation ensure that if causes (3), (4), or (5) have
> already occurred (at some hypothetical instant), that cause (1) does
> NOT also occur? Or,
> A2. Are multiple/indeterminate causes allowed?
>
>The main question here is whether choice A1 is actually implementable
>(without exorbitant cost/overhead) on all the platforms Java runs on.
Since you can't determine whether a thread returned from wait because
it was notified, timed out, or spuriously returned, I don't think you
need to worry about lost notifications in those cases.
However, you can distinguish the cases where a call to wait returned
by throwing IE, and the path for handling that case is typically
different than the case for handling normal returns from wait.
Bill
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT