ReentrantReadWriteLock in DUH2

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ReentrantReadWriteLock in DUH2

Koji Sekiguchi
I'm sorry if this is a stupid question but I'm curious
why DUH2 uses ReentrantReadWriteLock.
What is the purpose of it?

Thank you,

Koji

Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock in DUH2

Mark Miller-3
So that multiple threads can efficiently access the writer, but only  
one thread at a time does a commit. Adding docs with the writer is the  
'read' and committing is the write. If I remember correctly.

- Mark


On Nov 6, 2008, at 6:24 AM, Koji Sekiguchi <[hidden email]> wrote:

> I'm sorry if this is a stupid question but I'm curious
> why DUH2 uses ReentrantReadWriteLock.
> What is the purpose of it?
>
> Thank you,
>
> Koji
>
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock in DUH2

Koji Sekiguchi
 > So that multiple threads can efficiently access the writer, but only
one thread at a time does a commit.
 > Adding docs with the writer is the 'read' and committing is the
write. If I remember correctly.

You remember correctly, Mark. Because of the lock, <add/> is blocked
during <optimize/>, even if ConcurrentMergeScheduler is used, right?
I'd like to know why <add/> should be blocked during <optimize/>.

Koji


Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock in DUH2

Mike Klaas

On 6-Nov-08, at 7:48 AM, Koji Sekiguchi wrote:

> > So that multiple threads can efficiently access the writer, but  
> only one thread at a time does a commit.
> > Adding docs with the writer is the 'read' and committing is the  
> write. If I remember correctly.
>
> You remember correctly, Mark. Because of the lock, <add/> is blocked
> during <optimize/>, even if ConcurrentMergeScheduler is used, right?
> I'd like to know why <add/> should be blocked during <optimize/>.

The core reason is laid out in the comment:

       // open a new searcher in the sync block to avoid opening it
       // after a deleteByQuery changed the index, or in between deletes
       // and adds of another commit being done.

We want to open a searcher than corresponds exactly to the commit  
point (remember, an optimize is first and foremost a commit).

I don't see why there couldn't be an optimize command that doesn't  
commit, if that is desired.

-Mike