[
https://issues.apache.org/jira/browse/LUCENE-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206061#comment-13206061
]
Simon Willnauer commented on LUCENE-3761:
-----------------------------------------
bq. Hmm, but how to protect swapThingy in one thread while close() is called in
another?
well essentially its the same just a while() with a CAS... I will take a stab
at this soon.
bq. 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.
Shai, this is a common misconception lemme give you an example:
{code}
public class Deadlocker {
private static boolean ready;
public static void startThread() {
new Thread() {
public void run() {
System.out.println("T2: Waiting two seconds.");
try { sleep(2000); } catch (Exception e) { /* ignore */ }
System.out.println("T2: Setting ready = true");
setReady();
}
}.start();
}
public static synchronized void setReady() {
ready = true;
}
public static void main(String [] args) {
startThread();
System.out.println("T1: spinning.");
while (!ready) {
// Do nothing.
}
System.out.println("T1: Ready!");
}
}
{code}
if you run this on a 64 bit server vm this program will deadlock while on a
32bit client vm it won't. Now make "ready" volatile and you are good to go, you
can even remove the sync entirely. I leave the rest to you to figure out why
this happens... In general you
need to use special mechanisms to guarantee that communication happens between
these threads, as you would on a message passing system. Memory writes that
happen in one thread can "leak through" and be seen by another thread, but this
is by no means guaranteed. Without explicit communication, you can't guarantee
which writes get seen by other threads, or even the order in which they get
seen and this communication must be on both sides, reader and writer!
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
