Bug in reader/writer locks in Windows API

Original Article ↗ Hacker News Discussion ↗

A long‑standing bug in Windows’ slim reader/writer (SRW) locks has been uncovered via C++’s `std::shared_mutex`, allowing a thread requesting a shared lock to sometimes obtain exclusive access and potentially cause deadlocks in certain patterns. Commenters note that this behavior likely dates back to Vista and stems from subtle implementation choices and fairness trade‑offs in concurrency primitives, with alternative implementations in Wine and ReactOS appearing unaffected. The incident also highlights how hard it is for external developers to report low‑level Windows bugs through official channels, contrasting this with more open or better‑maintained ecosystems and prompting many to avoid reader–writer locks unless profiling proves they’re worth the complexity.

Windows SRWLOCK bug and impact

  • Bug is in Windows’ slim reader/writer (SRW) lock; std::shared_mutex on Windows is built on SRW, so it inherits the issue.
  • Scenario: after an exclusive owner releases the lock while multiple readers are trying to acquire shared access together, the lock can deadlock.
  • A Microsoft engineer confirmed an internal OS bug was filed; there is debate whether behavior is an implementation bug vs an underspecified contract.
  • Explanation from low-level analysis: non-atomic sequence in exclusive release lets a shared acquirer sometimes end up with an exclusive lock or otherwise “steal” the lock, leaving waiters unwoken.

Semantics and design of reader/writer locks

  • Several commenters note RW locks are deceptively complex and prone to subtle bugs; some avoid them unless profiling proves a benefit.
  • Shared mode is framed as an optimization, not a strict guarantee that all readers can always co-exist.
  • Fairness vs performance: SRW locks are intentionally unfair to avoid writer starvation and reduce context-switch overhead; this can block late-arriving readers even when existing readers are active.
  • Alternative patterns discussed: double-buffering, finer-grained locking, RCU-like schemes, shared_ptr-based versioning.

Correctness of the repro program

  • One commenter claims the sample has a data-race on a non-atomic thread count, suggesting that alone could cause hangs.
  • Others rebut: thread creation/join establishes a happens-before relationship; on x86 and with std::thread this pattern is considered safe, and making the count constexpr or atomic does not eliminate the bug.
  • Consensus in the thread leans toward “program is fine; SRW implementation is at fault.”

Alternative implementations and platforms

  • Rust’s RwLock and Mutex on Windows also use SRW; Mutex is safe because it only uses exclusive mode.
  • WINE and ReactOS use CAS-based designs and appear not to exhibit this bug.
  • Some share experiences building their own SRW/pushlock variants, emphasizing complexity despite small data structures.

Bug reporting and support experiences

  • Reporting Windows API bugs is described as very difficult; Feedback Hub is viewed as low-signal.
  • Workarounds include: filing “documentation bugs,” using GitHub issue trackers (for STL), or contacting engineers via social media.
  • Comparisons: Linux kernel and some Apple teams are described as more responsive, while large vendors often prioritize roadmaps and paying customers.
  • Broader frustration with corporate feedback systems: low-quality reports, first-line support scripts, and “shouting into the void” bug trackers.