lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Garski <mgar...@myspace-inc.com>
Subject RE: IndexWriter and AcquireRead/Write/Upgrade and deadlock in TestMergeAfterCopy
Date Tue, 10 Nov 2009 19:15:38 GMT
I'm totally fine with a ReaderWriterLock, and use ReaderWriterLockSlim
quite often in my own custom caches.

 

Michael

 

From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]

Sent: Tuesday, November 10, 2009 10:35 AM
To: lucene-net-dev@incubator.apache.org
Subject: IndexWriter and AcquireRead/Write/Upgrade and deadlock in
TestMergeAfterCopy

 

                There is currently a deadlock situation which is
occurring in TestMergeAfterCopy.  Basically, during the commit of a
transaction, you have a reader/writer lock (many reads, few writes)
which is coded incorrectly.

 

                There is a class in the .NET framework,
ReaderWriterLock, which provides these EXACT semantics.  There are
performance issues in the .NET 2.0 version, but in .NET 3.5, there is a
ReaderWriterLockSlim class which provides better performance, and is a
drop-in replacement for ReaderWriterLock.

 

                Since IndexReader has a Close method (which will
eventually be ported over to an IDisposable implementation), there
wouldn't be a need to change the API publically, as the ReaderWriterLock
can be disposed of in the close method.

 

                It would involve removing the locking code and the
counters used for those methods.  Instead, I'd just replace the methods
with calls to the appropriate method on the stored instance of the
ReaderWriterLock.

 

                Any objections, assuming it gets the test to pass?

 

                                - Nick


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message