[concurrency-interest] Volatile stores in constructors, disallowed to see the default value

Doug Lea dl at cs.oswego.edu
Wed Nov 27 08:49:14 EST 2013

On 11/27/2013 08:13 AM, Oleksandr Otenko wrote:

> If JLS already mentions that constructors with volatile stores in them are
> treated differently, then there is no ambiguity already.

It doesn't, but there are common cases where the effects can be
made identical to how final fields are treated (which is
convenient for JVMs).

Using only the simple cookbook approximations to JMM rules,
including that you cannot ever reorder volatile stores with
any other stores, plus the basic weakening transformations
(see "Removing Barriers" section in 
http://gee.cs.oswego.edu/dl/jmm/cookbook.html), you can reason as follows for 
the example:

class C {
   volatile int x, y;
   C(int a, int b) { x = a; y = b; }

There are no previous accesses of x or y.
And none except for the stores within the constructor.
And none until after the second store,
which cannot be reordered wrt other stores.

In this case, you don't need any fencing between the stores
to x and y. But you still need to prevent store reorderings
by the caller of the constructor, which can be done
in the same way it is done for classes with final fields:
placing a store fence at end of constructor.


More information about the Concurrency-interest mailing list