bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Myers (JIRA)" <>
Subject [jira] [Commented] (BVAL-173) Unsafe double-checked locking
Date Mon, 22 Apr 2019 22:19:00 GMT


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

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 (§ 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:
>             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

View raw message