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

From: Sarita Adve (
Date: Mon Aug 04 2003 - 01:21:58 EDT

> 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.

Sorry, Bill. I don't quite buy this. As I said, I was beginning to buy
your earlier argument, so this is not simply intransigence. To me, the
bizarreness co-efficient of tests 5 and 6 is more or less the same.
Telling a programmer (or even a compiler/JVM designer) anything like the
above is pretty useless.

Victor made the same case in his message on Friday very well, so I won't
repeat it again (unless people really disagree with this). Hans also
made a similar case. One thing from Victor's message I do want to
emphasize is that we should worry about ensuring that programmers can
detect data races easily (which we haven't focused much on yet), rather
than worry about how they will reason about the values a data race may

Nevertheless, I actually agree with an earlier message from Hans that
given that arrays can't be made volatile, some programmers will use data
races deliberately, and we should give them some obvious semantics.
That's the reason I'm ok with including happens-before consistency. But
the reasoning for test 5 is just too convoluted to be useful.

Given that we want to allow test 6, I don't see the case to prohibit
test 5, especially since allowing test 5 will simplify the model and
could potentially allow some future optimization.

That said, I am disturbed by both 5 and 6, and put them on my "to-do"
list of things to look at.


JavaMemoryModel mailing list -

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