RE: JavaMemoryModel: Spec on on wait and interrupts

From: Alexander Terekhov (
Date: Wed Jul 30 2003 - 06:27:10 EDT

David Holmes wrote:
> notify() is sufficient.

Probably not.

> notifyAll() would also be correct - though
> rather inefficient. The basic requirement is that given m threads
> sitting in wait() when a notify() occurs then at least one thread
> returns from wait() normally, provided all threads were not also
> interrupted (or timed out).
> This exposes a slight hole in that a late notify() passed on by
> an interrupted thread might actually select a thread that was not
> in the wait-set at the time of the orginal notify().

Yep. Pls take a look at:

cond_wait_cleanup_handler2(cond_wait_context_t* ctx)
  // cond_signal (ctx->cv); <-- WRONG
  /* broadcast is needed to prevent some "late"
     waiter from stealing a signal targeted at
     the old one. Example: two threads A and B
     waiting (that's reflected in shared data
     associated with mutex). Thread C locks the
     mutex and sees that A and B are waiting.
     C cancels A, issues a *signal* meant to
     unblock B and goes to wait on the same CV
     afterwards. Now, if A can consume a signal
     (that was meant to unblock B), it does
     need to make a *broadcast* to unblock B
     because a single signal can be delivered
     to C... waking it "spuriously" (that's OK)
     but leaving B blocked. */

  cond_broadcast (ctx->cv);

> They could have defined the effects of a timeout in the same way
> they defined cancellation - which makes it clear that a cancelled
> thread does not consume a signal. But even so it says "if the
> absolute time passed *before* the condition is signalled or
> broadcast". That seems to preclude the problem to me - but words
> are always open to interpretation.

Yeah. Pls take a look at:


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT