On 1/8/21 2:03 PM, Peter Levart wrote:
On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi <att...@openjdk.org> wrote:
IIUC, your changes mostly all flow from the decision to declare the fields as
non-volatile; if they were still declared as volatile then it'd be impossible
to observe null in them, I think (correct me if I'm wrong; it seems like you
thought through this quite thoroughly) as then I don't see how could a volatile
read happen before the initial volatile writes as the writes are part of the
ClassValues constructor invocation and the reference to the ClassValues object
is unavailable externally before the constructor completes. In any case, your
approach definitely avoids any of these concerns so I'm inclined to go with it.
It depends entirely on the guarantees of ClassValue and not on whether the
fields are volatile or not. If ClassValue publishes the BiClassValues object
via data race then even if the fields in BiClassValues are volatile and
initialized in constructor, the publishing write in ClassValue could get
reordered past
correction: past -> before
the volatile writes of the fields, so you could observe the fields
uninitialized.
I can't find in the spec of ClassValue any guarantees of ordering, but I guess
the implementation does guarantee safe publication. So if you want to rely on
ClassValue guaranteeing safe publication, you can pre-initialized the fields in
constructor and code can assume they are never null even if they are not
volatile.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1918
To explain: Normal writes that appear in program order before a volatile
write can not be observed to appear later than the volatile write. But
normal writes that appear in program order after a volatile write can be
observed to appear before the volatile write.
Regards, Peter
