[concurrency-interest] DCL clarification Immutable singelton

Vitaly Davidovich vitalyd at gmail.com
Thu Apr 10 08:28:50 EDT 2014

Right, the key here is java forbids adding second load for temporaries; if
this weren't true, all those benign data race coding practices wouldn't
work.  In Zhong's r2 example, compiler is allowed to make that
transformation since original code didn't have a load into a temp.

Sent from my phone
On Apr 10, 2014 1:39 AM, "Hans Boehm" <boehm at acm.org> wrote:

> 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/20140410/23d776be/attachment.html>

More information about the Concurrency-interest mailing list