Reader–writer lock

Readers can share access when they do not modify the protected state; writers exclude both other writers and readers. C++ shared mutexes distinguish shared from exclusive ownership and do not grant both modes concurrently.

“Read” is a property required by the synchronization protocol, not merely a query-like function name. Cache, counter or cursor mutations during a query need their own protection rather than being ignored as implementation details.

References: [1]

C++ lock_shared acquires shared ownership and unlock_shared releases it; exclusive operations use the corresponding mutex interface. try_lock_shared may fail even without another owner, so failure is not a reliable test that a writer exists.

Mode changes must follow the interface. C++ shared acquisition requires no prior ownership by the calling thread, rather than authorizing recursive acquisition or in-place upgrading. Releasing a read lock before acquiring a write lock leaves an interval in which state can change.

References: [1]

Reader admission policy can delay writers, while writer preference can delay readers. The general C++ shared-mutex requirements do not promise a FIFO fairness queue, so an implementation’s preference is not a universal contract.

Shared ownership still requires coordination. It enables reader overlap without proving that short queries outperform an ordinary mutex. Critical-section length, contention and implementation costs require measurement rather than a conclusion based only on the read/write ratio.

References: [1]