Bill Pugh wrote:
> 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.
You could lose a notification with a timeout. Most application code
would check the predicate when wait returns regardless, but it could
check for timeout first - especially with JSR-166 Condition.await when
timeout is indicated by a false return value.
> 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.
Yes - at the application level.
I'm not quite sure what you are reasoning here. If the VM is known to
lose notifications then application code that uses notify() must
account for that themselves - generally by issuing another notify().
I would prefer it if the VM did not lose notifications - but the fix
inside the VM is to do a notifyAll rather than a notify and that's a
painful fix.
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