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

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Nov 28 01:46:34 EST 2013


On 11/28/2013 02:51 AM, David Holmes wrote:
> Doug writes:
>> * Programmers do not expect that even though final fields are specifically
>> publication-safe, volatile fields are not always so.
> 
> Programmers don't grok "unsafe publication" - full stop! Once it is
> explained to them they have no reason to assume v0latile fields are special
> because only final fields are called out as such.

As I said before, the JMM is clear on the "special treatment of final
fields". It is a logical error to add "only" there and deny the
antedecent: "If P, then Q; Not P. Therefore, not Q". If field is final
(P) then there is a publication safety (Q). The field is not final (Not
P). Therefore, the publication safety is not gainable (Not Q).

This mistake will be even more evident if/when the JMM is overhauled to
allow volatiles to have the same formal semantics.

>> * For various implementation reasons, JVMs arrange that
>> volatile fields are publication safe anyway, at least in
>> cases we know about.
> 
> I think not - that is how this whole debate reignited due to a proposed
> change from the PPC64 folk to add the constructor barrier for volatiles (but
> that was in a misguided attempt to pass the jcstress tests that assumed the
> barrier was required).

I am going to re-assert the affected tests, marking these behaviors as
"not explicitly required by spec, but reasonably expected by users"
(there are already some tests that need the same marking, e.g.
ByteBuffer atomicity tests). If the correct implementation may make
users happier by providing stronger guarantees that is actually required
by spec, that is good, and aligned with what Doug wants in "further test
and validate JVMs as meeting this likely future spec."

-Aleksey.


More information about the Concurrency-interest mailing list