[concurrency-interest] Explicitly initializing volatile fields with default values

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Dec 17 19:24:52 EST 2015


On 12/18/2015 03:06 AM, Vitaly Davidovich wrote:
> On Thursday, December 17, 2015, Aleksey Shipilev
>      2) Read of default write(f, 0) -- these synchronize-with the first
>     action in the thread:
> 
>                            (default) write(v,0)
>                            (default) write(f,0)
>                                     |
>                                     | hb/sw
>                                     v
>                                  read(v):0 --hb/po--> read(f):0
> 
>      (One might wonder if that means you can see the default value for an
>     explicitly initialized volatile field, once you read the instance itself
>     -- you can! -- we have seen this with AtomicIntegers before)
> 
> Aren't instance fields initialized in textual order according to JLS?

Instance field initializers and instance initializers are run in the
lexical order, but this is irrelevant for:

> It's not clear to me how this would be allowed.  In particular, if
> volatile writes in ctor are supposed to have same ordering constraints
> as final field writes (that's supposedly going to be stated in next JMM
> revision), how was it possible to see AtomicInteger field with default
> value?

Volatile writes in constructors *are not* having the same ordering
constraints as final field writes. Some implementations might choose to
provide final-like behavior today, but it is not required by spec.

That remark was not supposed to re-fuel the discussion on volatile
writes in constructors themselves -- we seem to agree that's a problem,
we know that should be addressed in JMM update. Interested readers are
welcome to re-read the entire thread from the last time:

http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011954.html

But here, let's try to discuss the original "problem" with volatile
field initializers storing the default values with the current formal spec.

Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151218/6efd14f3/attachment-0001.bin>


More information about the Concurrency-interest mailing list