[concurrency-interest] DCL clarification Immutable singelton

Hans Boehm boehm at acm.org
Thu Apr 10 01:39:17 EDT 2014


Not all transformations that are valid in a single-threaded environment are
valid in Java.  (Or even in C/C++ with threads, which generally allow more
transformations than Java.)  In a single-threaded program, a compiler can
always introduce an x = x; assignment to an accessible program variable.
 In some contexts, that even turns out to be profitable, normally to
correct for a misspeculation.  That is not valid in C, C++, or Java, since
it may introduce a data race and hide a concurrent assignment to x.  (Gcc
occasionally does it, through about gcc 4.6, however.)

The exact Java semantics here are a bit unclear, since everyone now agrees
that the semantics for racing accesses in the Java memory model are a bit
buggy.  (One of the reasons to avoid them where possible.)  But if you look
at the rules, it is reasonably clear that reads from the same location can
be performed out of order.  There are good reasons for that.  Otherwise the
compiler wouldn't be able to reorder two loads through references x and y
without proving that they don't alias.  (This was one of the motivations
for the 2005 memory model revision.) And some hardware allows ordinary
loads from the same location to be performed out of order (either
intentionally or due to hardware errata).

Introducing a second load where the original code loaded it once into a
temporary, and used the temporary twice, is illegal in Java (but legal in
C++, since only racy programs can tell the difference.)

In general, there is no problem with the compiler introducing additional
dead loads, i.e. loads whose result isn't used.  As Zhong Yu points out,
that would happen on one control path if the compiler reorders the loads.
 But (a) that's fine, and (b) it's not an issue at the hardware level.
 Hardware issues speculative loads all the time, discarding the results if
the speculation proves wrong.

Hans


On Wed, Apr 9, 2014 at 7:47 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Compiler can assume single threaded execution unless told otherwise; in
> that case, introducing phantom reads will not change observable behavior of
> single threaded execution.
>
> Sent from my phone
> On Apr 9, 2014 9:35 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:
>
>> > http://stackoverflow.com/questions/14624365/immutability-and-reordering
>>
>> I agree with the conclusions, however I think it is flawed to argue
>> that if a transformation is valid from a single-thread point of view,
>> it is allowed by JMM. By that argument, a perfectly good code
>>     if( (tmp=resource) != null )
>>         return tmp;
>> can be transformed to a very bad code
>>     if( resource != null )
>>         return resource;   // [r1]
>> since they are equivalent in single-thread.
>>
>> JMM only talks about reads/writes in the program source. Here [r1] did
>> not exist in the program source, how could the compiler reason about
>> its effect? Can the compiler ever introduce such ghost reads with
>> confidence of correctness?
>>
>> Back to the original problem, can this code
>>     if( resource != null )
>>         return resource;
>> be transformed to
>>     tmp = resource;  // [r2]
>>     if( resource != null )
>>         return tmp;
>> ? The compiler now does two reads unconditionally; [r2] would be a
>> ghost read that did not exist in the source, unless the if() condition
>> is true, but how could the compiler reach that prediction?
>>
>> Zhong Yu
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140409/5b39eae9/attachment-0001.html>


More information about the Concurrency-interest mailing list