The document summarizes the .NET ReaderWriterLock class, which allows concurrent read access by multiple threads or exclusive write access by a single thread. It describes the namespace, assembly, constructors, properties, and methods of the ReaderWriterLock class. While ReaderWriterLock gives higher priority to reader threads, this can cause performance issues if there are more writer threads. The class supports recursion but maintaining thread counts adds overhead, making it around 6 times slower than using a Monitor lock.

1. OPERATING
SYSTEM
October 10
2012
PROJECT REPORT : READER/WRITER SOLUTION
Submitted to
Sir Raazi
Made by
Shahzeb Pirzada
Bariq Qadri

2. 2 | P a g e
Introduction:
The .NET Framework provides several threading locking primitives. The Reader Writer Solution
is one of them.
The Reader Writer Solution class is used to synchronize access to a resource. At any given time,
it allows concurrent read access to multiple (essentially unlimited) threads, or it allows write
access for a single thread. In situations where a resource is read frequently but updated
infrequently, a Reader Writer Solution will provide much better throughput than the exclusive
Monitor lock.
Namespace: System.Threading
This namespace provides all the class methods and properties required for implementation of
the Reader Writer Solution class.
Assembly:mscorlib (in mscorlib.dll)
Constructors:
ReaderWriterLock: The constructor used to initialize a new instance of the Reader Writer
Solution class.
Properties:
 Reader Lock Held: This property gets a value that point to whether the current thread
holds a reader lock.
 Writer Lock Held: This property gets a value that points to whether the current thread
holds the writer lock.
 Writer Sequence Num: Gets the current sequence number.
Method
 Acquire Reader Lock (Int32): Acquires a reader lock, using an Int32 value for the time-
out.
 Acquire Writer Lock (Int32): Acquires the writer lock, using an Int32 value for the time-
out.
 Release Lock: Releases the lock, regardless of the number of times the thread acquired
the lock.
 Release Reader Lock: Decrements the lock count.
 Release Writer Lock: Decrements the lock count on the writer lock.

3. 3 | P a g e
 Upgrade to Writer Lock (Int32): Upgrades a reader lock to the writer lock, using an
Int32 value for the time-out.
 Restore Lock: Restores the lock status of the thread to what it was before calling
Release Lock.
The problem with ReaderWriterLock is with its implementation. Several experts have slammed
this technique and found that outside of limited scenarios, it is actually far slower than the
Monitor. Enter method used to get an exclusive lock. ReaderWriterLock gives higher priority to
reader threads then writers. This makes sense if you have many readers and only a few writers.
So a lot of readers are able to read the resource while the writer has to wait longer to get the
lock. But what If you have equal or more writers. The process of favoring readers make writer
threads queue up and take a very long time to complete.
ReaderWriterLock intelligently handles recursive lock requests from the same thread. That is, if
the thread calls Acquire Reader Lock recursively (i.e., it already holds a reader lock), the lock is
granted immediately and the lock count is increased. The thread must still call Release Reader
Lock as many times as it called Acquire Reader Lock. Or, it can call Release Lock to reduce the
lock count to zero immediately. Be careful with Release Lock, though. If you subsequently call
Release Writer Lock or Release Reader Lock, the runtime will throw an exception.
A thread can hold a reader lock or a writer lock, but not both at the same time. Instead of
releasing a reader lock in order to acquire the writer lock, you can use Upgrade To Writer Lock
and Downgrade from Writer Lock.
In some situations, you might find that you're holding a reader lock and you need to upgrade to
a writer lock. In that situation, call Upgrade to Writer Lock, but understand that you don't get
the writer lock immediately. Your code will have to wait for any other readers in the queue to
release their locks, and will also have to wait behind any other writers that are already in the
write queue.
A thread should not call Acquire Writer Lock while it holds a reader lock. Doing so will cause the
thread to block while it holds the reader lock, and will lead to a deadlock if you use an infinite
timeout. You can call the Is Reader Lock Held method to determine if your thread currently
holds a reader lock before you attempt to acquire a writer lock.
Note that the opposite — calling Acquire Reader Lock while holding a writer lock — is just
fine. Since the thread has an exclusive lock on the resource, granting the lock is okay. However,
if you need to know whether your thread is currently holding a writer lock, you can call Is
Writer Lock Held.
The ReaderWriterLock class supports recursion; due to this it causes performance loss. in this
case the class needs to maintain a record of the number of times each thread acquires the lock
and increment and decrement the counter. When multiple reader threads acquire the same
lock (remember ReaderWriterLock class allows simultaneous reads), a counter is maintained for

4. 4 | P a g e
each thread. This overhead is what causes the ReaderWriterLock to pale in comparison to the
Monitor class. It is approximately 6 times slower.
Tools:
 MICROSOFT VISUAL STUDIO (2010)