[
https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206022#comment-13206022
]
Shai Erera commented on LUCENE-3761:
------------------------------------
bq. should either be volatile otherwise threads could spin unnecessarily long
since tryInc will fail until the reference is re-read from main memory.
I don't think that we need to make 'current' volatile. It's only changed from
swapSearcher which is synchronized, and therefore as soon as it changes, all
shared copies of that instance (in all threads) gets updated.
There are many web pages that discuss volatile vs. synchronized (just Google
those 3 words) and this page
(http://www.javamex.com/tutorials/synchronization_volatile.shtml) even suggests
that volatile is more expensive, because synchronization happens on each access
to the variable, while in synchronized it's only inside the synced block.
We check 'current' in ensureOpen() which happens on every API call, and I think
that volatile would therefore be more expensive. Also, I'm not sure that using
AtomicRef would be simpler code. And following Mike's comments, I prefer to
have an explicit synced swapSearcher.
> Generalize SearcherManager
> --------------------------
>
> Key: LUCENE-3761
> URL: https://issues.apache.org/jira/browse/LUCENE-3761
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3761.patch, LUCENE-3761.patch
>
>
> I'd like to generalize SearcherManager to a class which can manage instances
> of a certain type of interfaces. The reason is that today SearcherManager
> knows how to handle IndexSearcher instances. I have a SearcherManager which
> manages a pair of IndexSearcher and TaxonomyReader pair.
> Recently, few concurrency bugs were fixed in SearcherManager, and I realized
> that I need to apply them to my version as well. Which led me to think why
> can't we have an SM version which is generic enough so that both my version
> and Lucene's can benefit from?
> The way I see SearcherManager, it can be divided into two parts: (1) the part
> that manages the logic of acquire/release/maybeReopen (i.e., ensureOpen,
> protect from concurrency stuff etc.), and (2) the part which handles
> IndexSearcher, or my SearcherTaxoPair. I'm thinking that if we'll have an
> interface with incRef/decRef/tryIncRef/maybeRefresh, we can make
> SearcherManager a generic class which handles this interface.
> I will post a patch with the initial idea, and we can continue from there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
