Thomas Maslen wrote:
> > Why do we have to allow spurious wakeups at all?
>
> I don't think that Pthreads allowed spurious wakeups just
> to be perverse; I believe (but can't say for sure) that they did it
> because mandating no spurious wakeups would have ugly consequences
for
> the implementation on at least some platforms[*].
Thomas is right. This bas been discussed in the Pthreads world
ad-nauseum and for better or worse Pthreads is stuck with this. The
lastest Pthreads spec makes spurious wakeup even more likely than ever
before because pthread_cond_wait is allowed to return normally when
interrupted by a process signal (it may not return EINTR) and hence
this is a spurious wakeup as far as the application is concerned. I
have observed this on linux and some other UNIX variants that are
known for having bad signal-to-thread relationships.
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cond_w
ait.html
In principle we could clean this up at the JVM level and do away with
spurious wakeups altogether, but it's really not worth the effort. As
Dave Butenhof has stated re Pthreads, the bugs that get avoided by
forcing people to always wait in a loop far outweigh the perceived
inconvenience of having to do so - so enforcing this is a good thing.
Further, the effort required in the JVM to deal with this problem is
non-trivial, particularly when the underlying OS is far from assistive
with regards to the problem.
As far as the interrupt/notify interaction is concerned I would be
most happy to have all JVM's honour the order in which these things
occur, as per the "test cases" that Sylvia showed. Unfortunately, the
reality is somewhat different. While an interrupt before a notify
should (in my opinion) always result in InterruptedException being
thrown; there are reasons why the VM has a hard time telling if a wait
completed due to notification or interruption at the time the
interrupt flag is checked. There are ways to deal with this but it's a
question of the amount of burden being placed on the implementation.
So I concede to allowing the VM to recognise that a notified thread
was subsequently interrupted and cause it to return by throwing
InterruptedException *but* the VM must pass on a notification in case
one was consumed (and hence could cause a spurious wakeup).
This behaviour would be consistent with the pthread_cond_wait
behaviour where a cancelled thread may not consume a signal if it was
unblocked due to a (pthread_cond_)signal. Though I think pthreads
semantics would support the types of testcases that Sylvia showed.
>From the application programmers perspective the timing of interrupts
versus notifications are non-deterministic (not like the test cases)
and generally programs that support cancellation want the cancelled
thread to notice ASAP and act accordingly.
Just my 2c.
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:45 EDT