<p>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.</p>

<p>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.</p>

<p>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?</p>

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
```
...