OK, Sarita is right. The reason I said case 5 shouldn't be allowed:
* You should only have to reason about code that executed
also applies to case 6. In case 6, if you look only at the code
being executed:
>Thread 1
>r1 = A (1)
>if (r1 == 1)
> B = 1
>
>Thread 2
>r2=B (1)
>if (r2 == 1)
> A = 1
>if (r2 == 0)
> #### // won't look at it since it didn't execute
>
>Behavior in question: r1 == r2 == 1 allowed?
then the code is correctly synchronized, and r1 = r2 shouldn't be allowed.
OK, so what is Bill going to say now? [Watch out; Bill's talking
about himself in the third person]
We have to allow case 6. Simple, standard compiler optimizations can generate
the behavior in test case 6.
But I still don't think we should allow test case 5 or 10. I am
modifying the reason I gave earlier to:
* To understand how an execution occurred, you only need to reason
about things that
- did occur in code that was executed, or
- were guaranteed to occur.
[That 4 line description of the semantics is not entirely complete
(we got it down to one page; we can't get it down to 4 lines). To get
the full semantics, replace "guaranteed to occur" with "justified",
as described in the one-page semantics. This brings in other details,
such as causal orders and prohibited executions.]
I think this is a reasonable expectation for anyone trying to write
defensive code and/or debug a multithreaded program.
Bill
-------------------------------
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