Sylvia Else wrote:
> // Thread 3 may have now reached its wait call.
>
> // Interrupt thread 1. If thread 1 was woken up
> // above, but will throw Interrupted
> // Exception as a result of this call,
> // then thread 2 must be woken up - not
> // thread 3!
> t1.interrupt();
Right. t3 wasn't in the wait-set when the original notification came
in so it shouldn't get any late notification. That violates the
non-observable property that I claimed should hold. :(
I find myself wearing two hats on this one.
As a programmer I really would like a nice clean well-defined
programming model for wait/notify/interrupt such that reasonable
experiments (like the above - use of yield() notwithstanding :) ) work
as expected. It certainly makes writing TCK tests for this easier -
otherwise how the heck do you write a test for any of this stuff. ;-)
And it would follow the POSIX approach which has a very clearly
defined programming model that talks about events that block and
unblock threads - both notification and interrupt (signals and
cancellation) unblock a thread and so that thread can't be involved in
any later action on the wait-set/condition-variable.
But I can see the implementation issues for the VM with trying to
conform with this nice clean programming model. If it were trivial to
fix then I think it would be fixed.
Hmmmmm.
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