# Type Definition parking_lot::RwLock [−] [src]

    type RwLock<T> = RwLock<RawRwLock, T>;

A reader-writer lock

This type of lock allows a number of readers or at most one writer at any point in time. The write portion of this lock typically allows modification of the underlying data (exclusive access) and the read portion of this lock typically allows for read-only access (shared access).

This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.

The type parameter `T` represents the data that this lock protects. It is required that `T` satisfies `Send` to be shared across threads and `Sync` to allow concurrent access through readers. The RAII guards returned from the locking methods implement `Deref` (and `DerefMut` for the `write` methods) to allow access to the contained of the lock.

# Fairness

A typical unfair lock can often end up in a situation where a single thread quickly acquires and releases the same lock in succession, which can starve other threads waiting to acquire the rwlock. While this improves throughput because it doesn’t force a context switch when a thread tries to re-acquire a rwlock it has just released, this can starve other threads.

This rwlock uses eventual fairness to ensure that the lock will be fair on average without sacrificing throughput. This is done by forcing a fair unlock on average every 0.5ms, which will force the lock to go to the next thread waiting for the rwlock.

Additionally, any critical section longer than 1ms will always use a fair unlock, which has a negligible impact on throughput considering the length of the critical section.

You can also force a fair unlock by calling `RwLockReadGuard::unlock_fair` or `RwLockWriteGuard::unlock_fair` when unlocking a mutex instead of simply dropping the guard.

# Differences from the standard library `RwLock`

- Supports atomically downgrading a write lock into a read lock.
- Task-fair locking policy instead of an unspecified platform default.
- No poisoning, the lock is released normally on panic.
- Only requires 1 word of space, whereas the standard library boxes the `RwLock` due to platform limitations.
- Can be statically constructed (requires the `const_fn` nightly feature).
- Does not require any drop glue when dropped.
- Inline fast path for the uncontended case.
- Efficient handling of micro-contention using adaptive spinning.
- Allows raw locking & unlocking without a guard.
- Supports eventual fairness so that the rwlock is fair on average.
- Optionally allows making the rwlock fair by calling `RwLockReadGuard::unlock_fair` and `RwLockWriteGuard::unlock_fair`.

# Examples

    use parking_lot::RwLock;

    let lock = RwLock::new(5);

    // many reader locks can be held at once
    {
        let r1 = lock.read();
        let r2 = lock.read();
        assert_eq!(*r1, 5);
        assert_eq!(*r2, 5);
    } // read locks are dropped at this point

    // only one write lock may be held, however
    {
        let mut w = lock.write();
        *w += 1;
        assert_eq!(*w, 6);
    } // write lock is dropped here