Surely, you can't make multiple writes to a shared variable even if the
writes have the same value, because another thread could write a
different value between the multiple writes, making the multiple-write
visible.
Paul
Bill Pugh wrote:
> 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
-------------------------------
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