[concurrency-interest] Simulating effects of final fields with memory fences

Doug Lea dl at cs.oswego.edu
Tue Jun 19 07:28:10 EDT 2018

On 06/19/2018 03:00 AM, Peter Levart via Concurrency-interest wrote:

> But if that object is "thread-safe" - meaning that every access to its
> internal state (including its construction) is properly synchronized by
> the object itself, then I would really like to know when the use of
> storeStoreFence (as the last action in container constructor that
> constructs the containing object and writes the reference to the object)
> / loadLoadFence (as the 1st action in a method that dereferences the
> reference and uses the contained object) can bite me. 

As noted in j9mm doc, the storeStore vs release fence microoptimization
for constructors is based on "nothing need be guaranteed about
interactions with reads by the constructor", which refers to re-reads of
non-final fields (for example a final array ref vs a non-final index),
which would be extended here to pseudo-constructors. Which is usually OK.


More information about the Concurrency-interest mailing list