[jira] [Issue Comment Deleted] (BVAL-173) Unsafe double-checked locking

["John Myers (JIRA)" <ji...@apache.org>]

     [ 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)