Readers–writer lock

For the psychological difficulty sometimes encountered by writers, see Writer's block.

In computer science, a readers–writer (RW) or shared-exclusive lock (also known as a multiple readers/single-writer lock or multi-reader lock) is a synchronization primitive that solves one of the readers–writers problems. An RW lock allows concurrent access for read-only operations, while write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers or readers will be blocked until the writer is finished writing. A common use might be to control access to a data structure in memory that cannot be updated atomically and is invalid (and should not be read by another thread) until the update is complete.

Readers–writer locks are usually constructed on top of mutexes and condition variables, or on top of semaphores.

Upgradable RW lock

Some RW locks allow the lock to be atomically upgraded from being locked in read-mode to write-mode, as well as being downgraded from write-mode to read-mode. [1]

Priority policies

RW locks can be designed with different priority policies for reader vs. writer access. The lock can either be designed to always give priority to readers (read-preferring), to always give priority to writers (write-preferring) or be unspecified with regards to priority. These policies lead to different tradeoffs with regards to concurrency and starvation.

• Read-preferring RW locks allow for maximum concurrency, but can lead to write-starvation if contention is high. This is because writer threads will not be able to acquire the lock as long as at least one reading thread holds it. Since multiple reader threads may hold the lock at once, this means that a writer thread may continue waiting for the lock while new reader threads are able to acquire the lock, even to the point where the writer may still be waiting after all of the readers which were holding the lock when it first attempted to acquire it have released the lock. Priority to readers may be weak, as just described, or strong, meaning that whenever a writer releases the lock, any blocking readers always acquire it next.

• Write-preferring RW locks avoid the problem of writer starvation by preventing any new readers from acquiring the lock if there is a writer queued and waiting for the lock; the writer will acquire the lock as soon as all readers which were already holding the lock have completed. The downside is that write-preferring locks allows for less concurrency in the presence of writer threads, compared to read-preferring RW locks. Also the lock is less performant because each operation, taking or releasing the lock for either read or write, is more complex, internally requiring taking and releasing two mutexes instead of one. This variation is sometimes also known as "write-biased" readers–writer lock.

• Unspecified priority RW locks does not provide any guarantees with regards read vs. write access. Unspecified priority can in some situations be preferable if it allows for a more efficient implementation.

Implementation

Several implementation strategies for readers–writer locks exist, reducing them to synchronization primitives that are assumed to pre-exist.

Using two mutexes

Raynal demonstrates how to implement an R/W lock using two mutexes and a single integer counter. The counter, b, tracks the number of blocking readers. One mutex, r, protects b and is only used by readers; the other, g (for "global") ensures mutual exclusion of writers. The following is pseudocode for the lock-for-read operation:

• Lock r.
• Increment b.
• If b = 1, lock g.
• Unlock r.

Readers use a similar operation for unlocking, that, while holding the lock r, decrements b and unlocks g if this causes b to become equal to zero. Writers simply lock and unlock g directly. This implementation strategy gives weak priority to readers.

Using a condition variable and a mutex

Alternatively, a read-preferring R/W lock can be implemented in terms of a condition variable and an ordinary (mutex) lock, in addition to an integer counter and a boolean flag. The lock-for-read operation in this setup is:

• Input: mutex m, condition variable c, integer r (number of readers waiting), flag w (writer waiting).
• Lock m (blocking).
• While w:
  • wait c, m
• Increment r.
• Unlock m.

The lock-for-write operation is similar, but slightly different (inputs are the same as for lock-for-read):

• Lock m (blocking).
• While (w or r > 0):
  • wait c, m
• Set w to true.
• Unlock m.

Each of lock-for-read and lock-for-write has its own inverse operation. Releasing a read lock is done by decrementing r and signalling c if r has become zero (both while holding m), so that one of the threads waiting on c can wake up and lock the R/W lock. Releasing the write lock means setting w to false and broadcasting on c (again while holding m).

Programming language support

• POSIX standard pthread_rwlock_t and associated operations
• ReadWriteLock interface and the ReentrantReadWriteLock locks in Java version 5 or above
• Microsoft System.Threading.ReaderWriterLockSlim lock for C# and other .NET languages
• std::shared_mutex read/write lock in C++14
• boost::shared_mutex and boost::upgrade_mutex locks in Boost C++ Libraries
• SWRLOCK, added to the Windows operating system API as of Windows Vista.
• sync.RWMutex in Go
• Phase fair reader–writer lock, which alternates between readers and writers
• std::sync::RwLock read/write lock in Rust

Alternatives

The read-copy-update (RCU) algorithm is one solution to the readers–writers problem. RCU is wait-free for readers. The Linux kernel implements a special solution for few writers called seqlock.

See also

• Semaphore (programming)
• Mutual exclusion
• Scheduler pattern
• Balking pattern
• File locking
• Lock (computer science)