I'm wondering what the current thinking is concerning required reads and
writes. (I don't see where this is specified in the most recent docs.)
Hans writes:
> On the other side, there's some argument that a compiler should,
> aside from introducing extra reads and writes, be allowed to make
> favorable scheduling assumptions when compiling synchronization-
> free code, i.e. effectively assume that there are no races. [...]
>
> If you buy that, the compiler, while compiling x = r3, could reason
> that since there is no synchronization, it's safe to assume that
> thread 3 gets scheduled first, and z will be one. Thus r3 can be
> assumed to be one, and hence x = r3 can be optimized to x = 1.
> But there is no rule against stupidly failing to optimize r3 = z in
> the same way.
>
> x = 1
> r3 = z
>
Extrapolating further, does the JMM force any of the threads in any of these
cases to do anything?
That is, is the following result allowed in every case?
r1 = r2 = ... = rN = undefined
----- Original Message -----
From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'Bill Pugh'" <pugh@cs.umd.edu>; <javamemorymodel@cs.umd.edu>
Sent: Friday, August 01, 2003 4:44 PM
Subject: RE: JavaMemoryModel: The choice we need to make on test cases 5 and
10
I agree with Bill's and Jeremy's choices for all the test cases other
than 5 and 10. (I even agree if A and B are initially zero in test
case 6, as I assume they were supposed to be. )
I don't really care very much about 5 and 10.
On one side, intuitively they should be disallowed for the reasons
given in the web page, and because it's harder to reason about some programs
if they are allowed. But I have a hard time coming up with a real program
for which it matters.
On the other side, there's some argument that a compiler should, aside
from introducing extra reads and writes, be allowed to make favorable
scheduling assumptions when compiling synchronization-free code, i.e.
effectively assume that there are no races. This is a bit of a
generalization
of the rules about compiling synchronization free code in a single thread.
If you buy that, the compiler, while compiling x = r3, could reason that
since
there is no synchronization, it's safe to assume that thread 3 gets
scheduled first,
and z will be one. Thus r3 can be assumed to be one, and hence x = r3 can
be
optimized to x = 1. There is no rule against stupidly failing to optimize
r3 = z
in the same way. (Or perhaps it ends up getting scheduled in some other
context
in which z is cheaper to load then the constant one.) Thus we could
conceivably
justify transforming thread 4 to:
x = 1;
r3 = z;
which clearly makes the result possible.
As far as I'm concerned, the arguments in both directions are rather weak.
I'd
be happy to decide based on simplicity of the model.
Hans
-------------------------------
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