Is there a slim reader/writer lock for .NET 2.0?

Question

I've looked at the ReaderWriterLock in .NET 2.0 and the ReaderWriterLockSlim in .NET 3.5, and the slim version doesn't use kernel objects for the locking. For my context, which can potentially generate a large (but not huge) amount of objects, this sounds better.

But the code I write needs to be used in both .NET 2.0 and 3.5 during a transition period, so the 3.5 version, while looking good for my purposes, can't be used.

Does anyone have, or know of, a similar class that I can plug into .NET 2.0 and get some of the same benefits with?

Answer 1

As far as I know there isn't one from Microsoft (otherwise ReaderWriterLockSlim would be somewhat pointless) and if you find one from a third party other than one you trust to have excellent minds who have spent a long time thinking about, implementing and testing it, I wouldn't trust it. I certainly wouldn't trust a random CodeProject implementation, for example.

Do you have any concrete measures to suggest that using ReaderWriterLockSlim would be so much better that it's worth looking hard for alternatives for .NET 2.0? It's certainly a "nice to have" but I suspect the cases where it's massively significant are relatively rare. Unless you already know that locking is a bottleneck for you, I would stick with what you've got and just be ready to upgrade when you can.

You might want to try just using normal monitors rather than ReaderWriterLock though - in many cases the overhead of RWL outweighs the benefit.

Of course, it's all on a case-by-case basis - your app may be one which really would be made much, much faster by ReaderWriterLockSlim...

Answer 2

What about ReaderWriterGate from the PowerThreading library?

Answer 3

The resource locking library presented here by Jeffrey Richter seem to be very well thought out, and addresses performance concerns.

Answer 4

No hard lock ReadWriteLocker - This class is designed off of ReaderWriterLock Alternative, which is 20%-30% faster than ReaderWriterLock.

The differences that I have made are:

1. Supports upgrade locks through nesting write locks inside of read locks. Unlike ReaderWriterLock, upgrade locks are thread safe.
2. Has example collections which show you how to design thread safe collections. They aren't as efficient as .NET 4.0's PFX collections, but they have other benifits.
3. Cannot Deadlock if all locks that are initiated are unlocked. And that all other locking mechanisms run mutually exclusive to this locker.
4. Ability to detect deadlocks and turn off deadlock detection overhead, once you verify deadlocks do not happen.
5. Highly recursive, and many times more robust than ReaderWriterLock and ReaderWriterLockSlim.

I have spent a lot of work on it, and I hope it comes in useful. It is very new, as of now, and testing in regards to other locking mechanisms will be needed. And of course, everything is .NET 2.0 complaint.