How is a ReaderWriterLock shared amongst threads? Is it implemented with a singleton?

Question

When you want to use a ReaderWriterLock you declare it like this:

ReaderWriterLock rwLock = new ReaderWriterLock;

Well if you are doing that for all your different threads that are going to access some resource that you want to protect, they (presumably) are all using differnt ReaderWriterLock instances.

How is the ReaderWriterLock instance shared amongs threads?

Also, as a bonus, can someone confirm for me that what you are really "locking" is the ReaderWriterLock state, not any resource. Unlike lock(someResourceToLock), you aren't locking anything but the ReaderWriterLock instance's state (whether it is in read or write mode, and whether you are allowed to read and write yet).

Answer 1

If you are using the ReaderWriterLock rwLock = new ReaderWriterLock per thread or per method (i.e. as a method variable), then your code is most-likely broken. It is not a singleton; it relies on all threads accessing the protected data using the same lock. This is most commonly achieved by placing the lock in a field, i.e.

class Foo {
    ReaderWriterLock rwLock = new ReaderWriterLock();
    // lots of code accessing the rwLock field for this instance
}

Also - maybe consider ReaderWriterLockSlim in many scenarios; less overhead. Re your follow-up; when acquiring the lock you are changing the internal state (in a thread-safe manner) to preserve the "many-readers nand single-writer" expectation (perhaps blocking until that is possible, i.e. conflicting locks have been withdrawn).

Answer 2

How is the ReaderWriterLock instance shared amongs threads?

Create a single instance of ReaderWriterLock and use it from all threads that are accessing the shared resource you want to protect.

Also, as a bonus, can someone confirm for me that what you are really "locking" is the ReaderWriterLock state, not any resource. Unlike lock(someResourceToLock), you aren't locking anything but the ReaderWriterLock instance's state

You really are locking.

lock(obj) { ... } is just a short cut for (simplified here, the real implementation has some additional subtleties to handle edge cases):

Monitor.Enter(obj)
  ...
try {
} finally {
  Monitor.Exit(obj);
}

using the field in every reference type to hold the state used by Monitor.

---

As Marc notes, consider ReaderWriterLockSlim unless you need the fairness (threads guaranteed to enter in the order they starting waiting) that ReaderWriterLock gives.