At 10:11 AM -0700 7/28/03, Jerry Schwarz wrote:
>At 08:24 AM 7/28/2003, Bill Pugh wrote:
>>At 2:50 AM -0700 7/28/03, Jerry Schwarz wrote:
>>>
>>>That result can arise quite naturally if the compiler transforms Thread 2 to
>>>
>>> r1=x
>>> y=x
>>
>>Sorry, not legal. One of the key limitations on compilers in a
>>multithreaded context is that they cannot introduce additional
>>redundant reads of shared variables, unless it guarantees that the
>>reads will return the same value. A read of a shared variable into
>>a local variable needs to be considered an atomic action with just
>>one value stored into the local.
>
>
>In my view, if the programmer wants to impose that constraint then
>they need to declare the shared variable (i.e. the field) volatile.
>
>Put another way. If the code doesn't contain any threading
>constructs (volatile, synchronize, ...) then the compiler shouldn't
>be forced to treat the code is if it will be running in a
>multithreaded context.
>
I've been thinking about this for several years actually. I think the
only limitation on compilers in synchronization-free code is that
they may not introduce additional reads or writes of shared variables
if the additional reads/writes could be detected. It turns out that
you can introduce additional writes if you know that all of the
writes will write the same value, because this can't be detected.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:47 EDT