JavaMemoryModel: Hoist by my own petard; the real difference between 5 & 6

From: Bill Pugh (
Date: Sat Aug 02 2003 - 10:37:44 EDT

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.

JavaMemoryModel mailing list -

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