[
https://issues.apache.org/jira/browse/BVAL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823512#comment-16823512
]
John Myers commented on BVAL-173:
---------------------------------
"AFAIK" does not cut it: under the Java Memory Model, "a program is correctly
synchronized if and only if all sequentially consistent executions are free of
data races" and "when a program contains two conflicting accesses (§17.4.1)
that are not ordered by a happens-before relationship, it is said to contain a
data race." Unless there is something that establishes a happens-before
relationship between the write to value in one thread and the read of value in
another thread (taking the init == null path of the outermost if) then the code
is not safe.
There is indeed nothing establishing such a happens-before relationship in
either of those two classes. The volatile on init does not help: the Memory
Model states "a write to a volatile field (§8.3.1.4) happens-before every
subsequent read of that field." It does *not* state that it happens-before
reads of other fields, such as value.
> Unsafe double-checked locking
> -----------------------------
>
> Key: BVAL-173
> URL: https://issues.apache.org/jira/browse/BVAL-173
> Project: BVal
> Issue Type: Bug
> Reporter: John Myers
> Priority: Major
>
> The methods org.apache.bval.util.Lazy.get() and
> org.apache.bval.util.LazyInt.getAsInt() both use unsafe double-checked
> locking. In both cases, the fact that init is volatile does not, under the
> Java Memory Model, prevent an incompletely initialized value from being
> returned from the function.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
