OPERATING SYSTEM

October 10

2012PROJECT REPORT : READER/WRITER SOLUTION

Submitted toSir Raazi

Made byShahzeb PirzadaBariq Qadri

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.

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

3 | 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)

4 | P a g e