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:[email protected]] Sent: Tuesday, November 10, 2009 10:35 AM To: [email protected] 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
