Re: JavaMemoryModel: Proposed wording on lost interrupts

From: Sylvia Else (sylviae@optushome.com.au)
Date: Thu Aug 07 2003 - 01:21:47 EDT


At 03:14 PM 6/08/2003 -0400, Bil; wrote:

>The JSR133 expert group is still trying to decide whether to use a strong
>or weak version of the semantics associated with wait(), notify() and
>Interrupted Exceptions.

>Which of the following behaviors is allowed?
>
>a) T1 returns from the call to wait() by throwing interrupted exception,
> T2 returns normally from the call to wait()
>
>b) T1 returns normally from the call to wait() and still has a pending
> interrupt; T2 remains in the waitset for X
>
>c) T1 returns from the call to wait() by throwing interrupted exception;
> T2 remains in the waitset for X

My view is that (c) should definitely not be allowed.

Even the suggested 'strong' semantics are not the strongest possible.
Stronger semantics would require a definite outcome that is sensitive to
the order of the interrupt and notify, where the order is well defined.

I assume that the intent is that a practical implementation would be able
to defer the decision about what T1 should do until it actually runs again.
If T2 has a higher priority than T1, then you need to rely on the rule that
priorities are only advisory to avoid the situation where T2 sees in
retrospect that it should have woken up earlier than it did. To me this
means that the rules for RT Java will have to be changed yet again.

At the risk of repeating myself yet again, I remain unconvinced that strict
compliance with the original specification is unachievable at a reasonable
cost. This is a view I will continue to push during the public review period.

Sylvia.

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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