Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing.
Assembly: System.Core (in System.Core.dll)
'Declaration <HostProtectionAttribute(SecurityAction.LinkDemand, MayLeakOnAbort := True)> _ <HostProtectionAttribute(SecurityAction.LinkDemand, Synchronization := True, _ ExternalThreading := True)> _ Public Class ReaderWriterLockSlim _ Implements IDisposable 'Usage Dim instance As ReaderWriterLockSlim
The HostProtectionAttribute attribute applied to this type or member has the following Resources property value: MayLeakOnAbort | Synchronization | ExternalThreading. The HostProtectionAttribute does not affect desktop applications (which are typically started by double-clicking an icon, typing a command, or entering a URL in a browser). For more information, see the HostProtectionAttribute class or SQL Server Programming and Host Protection Attributes.
Use to protect a resource that is read by multiple threads and written to by one thread at a time. allows multiple threads to be in read mode, allows one thread to be in write mode with exclusive ownership of the lock, and allows one thread that has read access to be in upgradeable read mode, from which the thread can upgrade to write mode without having to relinquish its read access to the resource.
is similar to ReaderWriterLock, but it has simplified rules for recursion and for upgrading and downgrading lock state. avoids many cases of potential deadlock. In addition, the performance of is significantly better than ReaderWriterLock. is recommended for all new development.
By default, new instances of are created with the LockRecursionPolicy.NoRecursion flag and do not allow recursion. This default policy is recommended for all new development, because recursion introduces unnecessary complications and makes your code more prone to deadlocks. To simplify migration from existing projects that use Monitor or ReaderWriterLock, you can use the LockRecursionPolicy.SupportsRecursion flag to create instances of that allow recursion.
A thread can enter the lock in three modes: read mode, write mode, and upgradeable read mode. (In the rest of this topic, "upgradeable read mode" is referred to as "upgradeable mode", and the phrase "enter x mode" is used in preference to the longer phrase "enter the lock in x mode".)
Regardless of recursion policy, only one thread can be in write mode at any time. When a thread is in write mode, no other thread can enter the lock in any mode. Only one thread can be in upgradeable mode at any time. Any number of threads can be in read mode, and there can be one thread in upgradeable mode while other threads are in read mode.
has managed thread affinity; that is, each Thread object must make its own method calls to enter and exit lock modes. No thread can change the mode of another thread.
If a does not allow recursion, a thread that tries to enter the lock can block for several reasons:
A thread that tries to enter read mode blocks if there are threads waiting to enter write mode or if there is a single thread in write mode.
Blocking new readers when writers are queued is a lock fairness policy that favors writers. The current fairness policy balances fairness to readers and writers, to promote throughput in the most common scenarios. Future versions of the .NET Framework may introduce new fairness policies.
A thread that tries to enter upgradeable mode blocks if there is already a thread in upgradeable mode, if there are threads waiting to enter write mode, or if there is a single thread in write mode.
A thread that tries to enter write mode blocks if there is a thread in any of the three modes.
Upgrading and Downgrading Locks
Upgradeable mode is intended for cases where a thread usually reads from the protected resource, but might need to write to it if some condition is met. A thread that has entered a in upgradeable mode has read access to the protected resource, and can upgrade to write mode by calling the EnterWriteLock or TryEnterWriteLock methods. Because there can be only one thread in upgradeable mode at a time, upgrading to write mode cannot deadlock when recursion is not allowed, which is the default policy.
Regardless of recursion policy, a thread that initially entered read mode is not allowed to upgrade to upgradeable mode or write mode, because that pattern creates a strong probability of deadlocks. For example, if two threads in read mode both try to enter write mode, they will deadlock. Upgradeable mode is designed to avoid such deadlocks.
If there are other threads in read mode, the thread that is upgrading blocks. While the thread is blocked, other threads that try to enter read mode are blocked. When all threads have exited from read mode, the blocked upgradeable thread enters write mode. If there are other threads waiting to enter write mode, they remain blocked, because the single thread that is in upgradeable mode prevents them from gaining exclusive access to the resource.
When the thread in upgradeable mode exits write mode, other threads that are waiting to enter read mode can do so, unless there are threads waiting to enter write mode. The thread in upgradeable mode can upgrade and downgrade indefinitely, as long as it is the only thread that writes to the protected resource.
If you allow multiple threads to enter write mode or upgradeable mode, you must not allow one thread to monopolize upgradeable mode. Otherwise, threads that try to enter write mode directly will be blocked indefinitely, and while they are blocked, other threads will be unable to enter read mode.
A thread in upgradeable mode can downgrade to read mode by first calling the EnterReadLock method and then calling the ExitUpgradeableReadLock method. This downgrade pattern is allowed for all lock recursion policies, even NoRecursion.
After downgrading to read mode, a thread cannot reenter upgradeable mode until it has exited from read mode.
Entering the Lock Recursively
You can create a that supports recursive lock entry by using the ReaderWriterLockSlim(LockRecursionPolicy) constructor that specifies lock policy, and specifying LockRecursionPolicy.SupportsRecursion.
The use of recursion is not recommended for new development, because it introduces unnecessary complications and makes your code more prone to deadlocks.
For a that allows recursion, the following can be said about the modes a thread can enter:
A thread in read mode can enter read mode recursively, but cannot enter write mode or upgradeable mode. If it tries to do this, a LockRecursionException is thrown. Entering read mode and then entering write mode or upgradeable mode is a pattern with a strong probability of deadlocks, so it is not allowed. As discussed earlier, upgradeable mode is provided for cases where it is necessary to upgrade a lock.
A thread in upgradeable mode can enter write mode and/or read mode, and can enter any of the three modes recursively. However, an attempt to enter write mode blocks if there are other threads in read mode.
A thread in write mode can enter read mode and/or upgradeable mode, and can enter any of the three modes recursively.
A thread that has not entered the lock can enter any mode. This attempt can block for the same reasons as an attempt to enter a non-recursive lock.
A thread can exit the modes it has entered in any order, as long as it exits each mode exactly as many times as it entered that mode. If a thread tries to exit a mode too many times, or to exit a mode it has not entered, a SynchronizationLockException is thrown.
You may find it useful to think of the lock in terms of its states. A can be in one of four states: not entered, read, upgrade, and write.
Not entered: In this state, no threads have entered the lock (or all threads have exited the lock).
Read: In this state, one or more threads have entered the lock for read access to the protected resource.
Upgrade: In this state, one thread has entered the lock for read access with the option to upgrade to write access (that is, in upgradeable mode), and zero or more threads have entered the lock for read access. No more than one thread at a time can enter the lock with the option to upgrade; additional threads that try to enter upgradeable mode are blocked.
Write: In this state, one thread has entered the lock for write access to the protected resource. That thread has exclusive possession of the lock. Any other thread that tries to enter the lock for any reason is blocked.
The following table describes the transitions between lock states, for locks that do not allow recursion, when a thread t takes the action described in the leftmost column. At the time it takes the action, t has no mode. (The special case where t is in upgradeable mode is described in the table footnotes.) The top row describes the starting state of the lock. The cells describe what happens to the thread, and show changes to the lock state in parentheses.
Not entered (N)
t enters read mode
t enters (R).
t blocks if threads are waiting for write mode; otherwise, t enters.
t blocks if threads are waiting for write mode; otherwise, t enters.1
t enters upgradeable mode
t enters (U).
t blocks if threads are waiting for write mode or upgrade mode; otherwise, t enters (U).
t enters write mode
t enters (W).
1 If t starts out in upgradeable mode, it enters read mode. This action never blocks. The lock state does not change. (The thread can then complete a downgrade to read mode by exiting upgradeable mode.)
2 If t starts out in upgradeable mode, it blocks if there are threads in read mode. Otherwise it upgrades to write mode. The lock state changes to Write (W). If t blocks because there are threads in read mode, it enters write mode as soon as the last thread exits read mode, even if there are threads waiting to enter write mode.
When a state change occurs because a thread exits the lock, the next thread to be awakened is selected as follows:
First, a thread that is waiting for write mode and is already in upgradeable mode (there can be at most one such thread).
Failing that, a thread that is waiting for write mode.
Failing that, a thread that is waiting for upgradeable mode.
Failing that, all threads that are waiting for read mode.
The subsequent state of the lock is always Write (W) in the first two cases and Upgrade (U) in the third case, regardless of the state of the lock when the exiting thread triggered the state change. In the last case, the state of the lock is Upgrade (U) if there is a thread in upgradeable mode after the state change, and Read (R) otherwise, regardless of the prior state.
The following example shows a simple synchronized cache that holds strings with integer keys. An instance of is used to synchronize access to the Dictionary(Of TKey, TValue) that serves as the inner cache.
The example includes simple methods to add to the cache, delete from the cache, and read from the cache. To demonstrate time-outs, the example includes a method that adds to the cache only if it can do so within a specified time-out.
To demonstrate upgradeable mode, the example includes a method that retrieves the value associated with a key and compares it with a new value. If the value is unchanged, the method returns a status indicating no change. It no value is found for the key, the key/value pair is inserted. If the value has changed, it is updated. Upgradeable mode allows the thread to upgrade from read access to write access as needed, without the risk of deadlocks.
The example includes a nested enumeration that specifies the return values for the method that demonstrates upgradeable mode.
The example uses the default constructor to create the lock, so recursion is not allowed. Programming the is simpler and less prone to error when the lock does not allow recursion.
Imports System Imports System.Threading Imports System.Collections.Generic Public Class SynchronizedCache Private cacheLock As New ReaderWriterLockSlim() Private innerCache As New Dictionary(Of Integer, String) Public Function Read(ByVal key As Integer) As String cacheLock.EnterReadLock() Try Return innerCache(key) Finally cacheLock.ExitReadLock() End Try End Function Public Sub Add(ByVal key As Integer, ByVal value As String) cacheLock.EnterWriteLock() Try innerCache.Add(key, value) Finally cacheLock.ExitWriteLock() End Try End Sub Public Function AddWithTimeout(ByVal key As Integer, ByVal value As String, _ ByVal timeout As Integer) As Boolean If cacheLock.TryEnterWriteLock(timeout) Then Try innerCache.Add(key, value) Finally cacheLock.ExitWriteLock() End Try Return True Else Return False End If End Function Public Function AddOrUpdate(ByVal key As Integer, _ ByVal value As String) As AddOrUpdateStatus cacheLock.EnterUpgradeableReadLock() Try Dim result As String = Nothing If innerCache.TryGetValue(key, result) Then If result = value Then Return AddOrUpdateStatus.Unchanged Else cacheLock.EnterWriteLock() Try innerCache.Item(key) = value Finally cacheLock.ExitWriteLock() End Try Return AddOrUpdateStatus.Updated End If Else cacheLock.EnterWriteLock() Try innerCache.Add(key, value) Finally cacheLock.ExitWriteLock() End Try Return AddOrUpdateStatus.Added End If Finally cacheLock.ExitUpgradeableReadLock() End Try End Function Public Sub Delete(ByVal key As Integer) cacheLock.EnterWriteLock() Try innerCache.Remove(key) Finally cacheLock.ExitWriteLock() End Try End Sub Public Enum AddOrUpdateStatus Added Updated Unchanged End Enum End Class
Windows 7, Windows Vista, Windows XP SP2, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003
The .NET Framework and .NET Compact Framework do not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.