Bill Pugh wrote:
>
> On Apr 9, 2004, at 8:11 AM, Vijay Saraswat wrote:
>
>> Boehm, Hans wrote:
>>
>>> As far as I can tell, requiring the precise exception model for
>>> Thread.stop()
>>>
>>
>> I am not worried about Thread.stop(). Lets ignore it -- its
>> deprecated after all.
>>
>> Let me make the high-level argument of my previous message concrete.
>> I hope this helps to better communicate my worry.
>>
>> Consider Test Case 6Ex, a variant of test case 6.
>> ----------------------------------------------------
>> Causality test case 6Ex
>>
>> Initially, x = y = 0, z = null
>>
>> Thread 1
>> r1 = x
>> if r1 == 1
>> y = 1
>>
>> Thread 2
>> r2 = y
>> if (r2 == 1)
>> x=1
>> z = comp()
>> r4 = z.a
>> if (r2 == 0)
>> x=1
>>
>> Behavior in question: r1 == r2 == 1
>>
>> ----------------------------------------------
>>
>> Here, comp() is some terminating computation and the compiler cant
>> establish after the assignment to z that z is not null.
>>
>> Should the behavior be allowed?
>
>
> OK, so this is really just the same as
> Initially, x = y = 0, z = null
>
> Thread 1
> r1 = x
> if r1 == 1
> y = 1
>
> Thread 2
> r2 = y
> if (r2 == 1)
> x=1
> z = comp()
> if (z == null) throw new NullPointerException();
> else {
> r4 = z.a
> if (r2 == 0)
> x=1
> }
>
> Behavior in question: r1 == r2 == 1
>
> OK, I'm going to assume that comp does not interact with other threads.
> In that case, since Java is deterministic although than for thread
> scheduling, then comp either returns null or
> it doesn't. If comp does not return null, then r1 = r2 = 1 is legal.
> This is just normal reasoning
> about control flow, nothing more.
Hmm... Why make that assumption --- cant make assumptions simply because
they simplify one's life! On the contrary!
Java is of course not deterministic. (a) It has math.random, (b) it has
native method calls (c) it has input (!!), (d) it has assignment and
thread scheduling....The semantics cannot depend on "since Java is
deterministic".
The worrisome issue here is that as soon as you have the possibility of
throwing errors, then because of precise exceptions, the implementation
has to wait (at runtime) to determine whether the exception is actually
thrown or not. (Is there any other way of ensuring precise exception
semantics? I cant see mechanisms for rolling back other threads who
might have been contiminated by seeing values that should not have been
generated because the exception got thrown...)
So effectively there is a barrier here of some sort. Does it translate
to some implicit "happens before" edges....? (I think Sarita is asking
the same thing..)
Consider the "compile-time" reasoning that was used in Test 6 to
establish this case: "Intrathread analysis could determine that thread
2 always writes 1 to A and hoist the write to the beginning of thread 2."
Well, this reasoning is invalid for Test 6Ex.
So back to my question. This is a test case. How do we determine what
this test case should do, independent of what a candidate model says
this should do (or doesnt)?
Need to think this through....
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:03 EDT