[concurrency-interest] DCL clarification Immutable singelton

Zhong Yu zhong.j.yu at gmail.com
Thu Apr 10 04:23:10 EDT 2014

On Thu, Apr 10, 2014 at 12: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.

That makes sense, so the transformation is valid after all? Phew.

> 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

More information about the Concurrency-interest mailing list