Home/ Questions/Q 79063
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T21:05:13+00:00

I’ve looked at the ReaderWriterLock in .NET 2.0 and the ReaderWriterLockSlim in .NET 3.5,

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 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…

    • 0