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:
http://terekhov.de/DESIGN-futex-CV-with-async.cancelable-wait.txt
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:
http://opengroup.org/austin/mailarchives/austin-review-l/msg01561.html
regards,
alexander.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT