Alexander Terekhov wrote:
> I think that the spec should just say that "a thread that exits
> the m.wait() by throwing IE shall not consume any notification
> that may be directed concurrently at m if there are other threads
> waiting on m".
While I think that captures the intent, the wording might be subject
to interpretation (yes I know it's the POSIX wording).
> I may be just missing and/or misunderstanding
> something, but the right way to do it on some implementation that
> does allow for such thread to consume a notification is to perform
> a broadcast -- call notifyAll(). AFAICS notify() isn't sufficient,
> so to speak.
notify() is sufficient. 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(). This implies that a
thread could notify itself - which I find unsettling.
> FYI, POSIX is "allegedly broken" with respect to CV
> signaling and "concurrent timouts". It seem that POSIX does allow
> for timedout thread to consume a signal... and that "alleged fact"
> somewhat surprises some folks.
Hmmm here's the text:
"The pthread_cond_timedwait() function shall be equivalent to
pthread_cond_wait(), except that an error is returned if the absolute
time specified by abstime passes (that is, system time equals or
exceeds abstime) before the condition cond is signaled or broadcasted,
or if the absolute time specified by abstime has already been passed
at the time of the call."
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.
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:48 EDT