> Date: Fri, 01 Sep 2000 13:32:14 -0700
^^^ As a side note, you should probably look into that. I'm pretty sure
that isn't today's date.
> ------------------------------------------------------------------------
>
> Consider the following executions:
>
> Execution 1 Execution 2
> 1. x=1 1. x==1
> //------------- no barriers //---------------- no barriers
> 2. x=2 2. x=2
> 3. x==1 3. x==1
>
> Execution 1 is not permitted by the model. Execution 2 is permitted.
What are these executions of? Are these taking place in multiple threads?
I'm not sure why you think Execution 1 is somehow not permitted and
Execution 2 is. It the == operation supposed to test equality and return
true or false? If so, then this is just a few lines of code: what would
prevent them from being executed?
I think that the problem is that I really don't understand this example.
> Consider the following program:
>
>
> Thread 1 Thread 2
>
> while (true) int k = -INF;
> { while (true) {
> i++; if (k>i) OUCH;
> } k = i;
> }
>
> The question is "Can this program get to execute the OUCH"?
> The proposed spec permits it.
> Original Java is Coherent, so it forbids that. As far as I understand,
> it is also forbidden in CRF.
A simple solution to this problem is to make i volatile. The agreed-upon
message to programmers is "don't have inter-thread communication unless
the variable is volatile or you are using synchronization".
I, personally, don't think that there is any reason to make this legal
without the use of volatile. Maybe a compiler will decide to hoist the
read of i in the if statement and not the other read of i. That shouldn't
be explicitly prohibited.
As a side note, there is no reason to expect a compiler not to unroll the
loop once, and then eliminate the k = i inside the loop so that it only
gets executed once. A compiler could also register-allocate i, so it
never is seen to change. To a programmer who hasn't "gotten the message",
this behavior might be just as surprising as non-monotonicity. But we
wouldn't think about making those optimizations illegal.
This is my humble opinion, of course, and may or may not reflect
reality...
Our proposed spec (and all of the others) doesn't discuss aliasing, and
just deals with the memory model on the level of memory accesses. Aliasing
is a syntactic issue, as you say: our spec deals (almost exclusively) with
the JVM, not the Java language.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT