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

David Holmes davidcholmes at aapt.net.au
Wed Nov 27 17:44:06 EST 2013

Doug writes:
> On 11/27/2013 09:06 AM, Vitaly Davidovich wrote:
> > But the issue is whether assignment of the new C instance to
> > some other memory must occur after the volatile stores.
> Sorry for mis-remembering why I had treated this issue as
> basically settled:
> Unless a JVM always pre-zeros memory (which usually not a good
> option), then
> even if not explicitly initialized, volatile fields must be zeroed
> in the constructor body, with a release fence before publication.

Thank you for clarifying that. So what you are describing is an
implementation action that is only necessary if the memory is not
pre-zeroed. There is nothing in the spec to require this.


> And so even though there are cases in which the JMM does not
> strictly require mechanics preventing publication reordering
> in constructors of classes with volatile fields, the only good
> implementation choices for JVMs are either to use non-volatile writes
> with a trailing release fence, or to perform each volatile write
> with full fencing. Either way, there is no reordering with publication.
> Unfortunately, programmers cannot rely on a spec to guarantee
> it, at least until the JMM is revised.
> -Doug
> _______________________________________________
> 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