On Mar 26, 2004, at 7:45 PM, David Holmes wrote:
> Bill Pugh wrote:
>> Remember the golden rule of compiler optimizations:
>>
>> If you can't be caught, it isn't illegal.
>>
>> For example, you are allowed to reorder memory accesses and accesses
>> to
>> a thread local volatile. Similarly, if an object is thread local,
>> synchronization
>> on that object is a no-op and reads and writes can be freely moved out
>> of the synchronization block (or you can just remove the
>> synchronization block).
>>
>> There are not transformations that are explicitly allowed by the
>> memory
>> model.Rather, you can use the memory model to show that they are not
>> detectable, in that they do not allow any additional behaviors.
>
> Okay. I'll leave the formalities to others, but informally, once we
> allow
> for the removal of thread-local volatiles and thread-local sync then
> the
> "roach motel" rules are exact/complete. ie if my code contains no
> thread-local volatiles or thread-local sync then I CAN explain the
> behaviour
> in terms of the "barriers" (memory AND code-motion) inherent in the
> "roach
> motel" rules. Right?
>
> David Holmes
>
No.
Consider:
Initially, x = y = v = 0, v is volatile
Thread 1:
r3 = y
v = 1
r2 = v
x = 1
Thread 2:
r1 = v
v = r1+1
Thread 3:
r4 = x
y = r4
Execution in question:
r1 = 1, r2 = 2, r3 == r4 == 1
OK, so v is not thread local, and so it can't be removed.
Roach motel order would prevent reordering the read of y or the write
of x in thread 1.
But the ordering constraints on x and y are only visible to thread 2,
not thread 3.
So it is possible for thread 3 to see the write to x by thread 1, and
for thread
1 to see the write to y by thread 3.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT