lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <>
Subject Re: is the classes ended with PerThread(*PerThread) multithread
Date Tue, 28 Dec 2010 09:02:23 GMT
Hey there,

so what you are looking at are classes that are created per Thread
rather than shared with other threads. Lucene internally rarely
creates threads or subclasses Thread, Runnable or Callable
(ParallelMultiSearcher is an exception or some of the merging code).
Yet, inside the indexer when you add (update) a document Lucene
utilizes the callers thread rather than spanning a new one. When you
look at there should be a method callled
getThreadState. Each indexing thread, lets say in updateDocument, gets
its Thread-Private DocumentsWriterThreadState. This thread state holds
a DocConsumerPerThread obtained from the DocumentsWriters DocConsumer
(see the indexing chain). DocConsumerPerThread in that case is some
kind of decorator that hold other DocConsumerPerThread instances like
TermsHashPerThread etc.

The general pattern is for each DocConsumer you can get a
DocConsumerPerThread for your indexing thread which then consumes the
document you are processing right now.

I hope that helps....


On Tue, Dec 28, 2010 at 4:19 AM, xu cheng <> wrote:
> hi all:
> I'm new to dev
> these days I'm reading the source code in the index package
> and I was confused.
> there are classes with suffix PerThread such as DocFieldProcessorPerThread,
> DocInverterPerThread, TermsHashPerThread, FreqProxTermWriterPerThread.
> in this mailing-list, I was told that they are multithreaded.
> however, there are some difficulties for me to understand!
> I see no sign that they inherited from the Thread , or implement the
> Runnable, or something else??
> how do they map to the OS thread??
> thanks ^_^

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message