[
https://issues.apache.org/jira/browse/SOLR-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366281#comment-14366281
]
Yonik Seeley edited comment on SOLR-7259 at 3/17/15 11:14 PM:
--------------------------------------------------------------
bq. How is it broken?
There are a few issues...
The most basic is that LazyPluginHolder uses the "inst" member directly in
createInst().
This means that even without considering complex reordering and memory barrier
issues, the code is incorrect. It publishes the object as soon as it is
created. Another thread coming along can thus use that object before
initInstance() has been called, or even during the execution of initInstance().
But when we do take the java memory model into account, we need to publish
objects safely (i.e. avoid the classic trap behind double-checked locking)
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Depending on how close() is called (i.e. the possible contexts of it's use),
there's a race where one thread may be constructing an object and another
thread goes through and closes everything, missing the object under
construction that will then presumably never have close() called on it. This
last one may not actually be an issue if it's never called concurrently with
other methods.
was (Author: [email protected]):
bq. How is it broken?
There are a few issues...
The most basic is that LazyPluginHolder uses the "inst" member directly in
createInst().
This means that even without considering complex reordering and memory barrier
issues, the code is incorrect. It publishes the object as soon as it is
created. Another thread coming along can thus use that object before
initInstance() has been called, or even during the execution of initInstance().
But when we do take the java memory model into account, we need to publish
objects safely (i.e. avoid the classic trap behind double-checked locking)
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Depending on how close() is called (i.e. the possible contexts of it's use),
there's a race where one thread may be constructing an object and another
thread goes through and closes everything, missing the object under
construction that will then presumably never have close() called on it.
> lazy loading not thread safe
> ----------------------------
>
> Key: SOLR-7259
> URL: https://issues.apache.org/jira/browse/SOLR-7259
> Project: Solr
> Issue Type: Bug
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
>
> It looks like SOLR-7073 broke the thread safety of lazy loaded components,
> unsafely publishing the component.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
