[jira] [Comment Edited] (SOLR-7259) lazy loading not thread safe

["Yonik Seeley (JIRA)" <ji...@apache.org>]

    [ 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: yseeley@gmail.com):
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org