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?
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
...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With