Defines a lock that supports single writers and multiple readers.
Assembly: mscorlib (in mscorlib.dll)
Thetype exposes the following members.
|AcquireReaderLock(Int32)||Acquires a reader lock, using an Int32 value for the time-out.|
|AcquireReaderLock(TimeSpan)||Acquires a reader lock, using a TimeSpan value for the time-out.|
|AcquireWriterLock(Int32)||Acquires the writer lock, using an Int32 value for the time-out.|
|AcquireWriterLock(TimeSpan)||Acquires the writer lock, using a TimeSpan value for the time-out.|
|AnyWritersSince||Indicates whether the writer lock has been granted to any thread since the sequence number was obtained.|
|DowngradeFromWriterLock||Restores the lock status of the thread to what it was before UpgradeToWriterLock was called.|
|Equals(Object)||Determines whether the specified object is equal to the current object. (Inherited from Object.)|
|GetHashCode||Serves as the default hash function. (Inherited from Object.)|
|GetType||Gets the Type of the current instance. (Inherited from Object.)|
|ReleaseLock||Releases the lock, regardless of the number of times the thread acquired the lock.|
|ReleaseReaderLock||Decrements the lock count.|
|ReleaseWriterLock||Decrements the lock count on the writer lock.|
|RestoreLock||Restores the lock status of the thread to what it was before calling ReleaseLock.|
|ToString||Returns a string that represents the current object. (Inherited from Object.)|
|UpgradeToWriterLock(Int32)||Upgrades a reader lock to the writer lock, using an Int32 value for the time-out.|
|UpgradeToWriterLock(TimeSpan)||Upgrades a reader lock to the writer lock, using a TimeSpan value for the time-out.|
The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and . ReaderWriterLockSlim is recommended for all new development. ReaderWriterLockSlim is similar to , but it has simplified rules for recursion and for upgrading and downgrading lock state. ReaderWriterLockSlim avoids many cases of potential deadlock. In addition, the performance of ReaderWriterLockSlim is significantly better than .
is used to synchronize access to a resource. At any given time, it allows either concurrent read access for multiple threads, or write access for a single thread. In a situation where a resource is changed infrequently, a ReaderWriterLock provides better throughput than a simple one-at-a-time lock, such as Monitor.
ReaderWriterLock works best where most accesses are reads, while writes are infrequent and of short duration. Multiple readers alternate with single writers, so that neither readers nor writers are blocked for long periods.
Holding reader locks or writer locks for long periods will starve other threads. For best performance, consider restructuring your application to minimize the duration of writes.
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 UpgradeToWriterLock and DowngradeFromWriterLock.
Recursive lock requests increase the lock count on a lock.
Readers and writers are queued separately. When a thread releases the writer lock, all threads waiting in the reader queue at that instant are granted reader locks; when all of those reader locks have been released, the next thread waiting in the writer queue, if any, is granted the writer lock, and so on. In other words, ReaderWriterLock alternates between a collection of readers, and one writer.
While a thread in the writer queue is waiting for active reader locks to be released, threads requesting new reader locks accumulate in the reader queue. Their requests are not granted, even though they could share concurrent access with existing reader-lock holders; this helps protect writers against indefinite blockage by readers.
Most methods for acquiring locks on a ReaderWriterLock accept time-out values. Use time-outs to avoid deadlocks in your application. For example, a thread might acquire the writer lock on one resource and then request a reader lock on a second resource; in the meantime, another thread might acquire the writer lock on the second resource, and request a reader lock on the first. Unless time-outs are used, the threads deadlock.
If the time-out interval expires and the lock request has not been granted, the method returns control to the calling thread by throwing an ApplicationException. A thread can catch this exception and determine what action to take next.
Time-outs are expressed in milliseconds. If you use a System.TimeSpan to specify the time-out, the value used is the total number of whole milliseconds represented by the TimeSpan. The following table shows the valid time-out values in milliseconds.
The thread waits until the lock is acquired, regardless of how long it takes. For methods that specify integer time-outs, the constant Infinite can be used.
The thread does not wait to acquire the lock. If the lock cannot be acquired immediately, the method returns.
The number of milliseconds to wait.
With the exception of -1, negative time-out values are not allowed. If you specify a negative integer other than -1, a time-out value of zero is used instead. (That is, the method returns without waiting, if the lock cannot be acquired immediately.) If you specify a TimeSpan that represents a negative number of milliseconds other than -1, ArgumentOutOfRangeException is thrown.
The HostProtectionAttribute attribute applied to this type or member has the following Resources property value: 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.
Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)