[
https://issues.apache.org/jira/browse/BVAL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Myers updated BVAL-173:
----------------------------
Comment: was deleted
(was: "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)
