views:

767

answers:

4

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?

+2  A: 

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

Jon Skeet
My data structures are for a service-container IoC type of thing, and they will have data structures containing instances, which will during start have mostly writes on a single thread, but then after that mostly reads on multiple threads, so I was hoping to avoid kernel objects and just lock()...
Lasse V. Karlsen
I will just separate out the locking code into my own class and use that, and just use exclusive locks for now, then I can always plug in a better lock later if it becomes necessary
Lasse V. Karlsen
That sounds like the right way to go, yes.
Jon Skeet
A: 

What about ReaderWriterGate from the PowerThreading library?

Dmitri Nesteruk
Unfortunately, that class is suitable only for request/response type scenarios, since it returns immediately and calls back to your code when it can obtain the lock, whereas in my code, I need the lock because I need to return the result of accessing the data structure.
Lasse V. Karlsen
+2  A: 

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

SytS
+1  A: 

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.

TamusJRoyce
I will definitely look at this one, thanks for publishing it and letting me know about it.
Lasse V. Karlsen