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

Andrew Haley aph at redhat.com
Tue Jun 19 12:26:02 EDT 2018


On 06/19/2018 08: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. I really just want to make sure that field 'y'
> is never seen as null in method m(). Just like it was a primitive
> field. Is my thinking correct or are there flaws in it?

Yes, probably.  What none of us here understand is why you seem to
want to know if it's possible to dance around the rim of the volcano.
Sure, it's possible.  After a lot of arguing, I was persuaded that
StoreStore was enough for a constructor.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


More information about the Concurrency-interest mailing list