5 ms·

Misleading title? This is a Windows API bug with the slim reader/writer (SRW) locks. It's just that the bug was discovered via std::shared_mutex as that is imp

Misleading title? This is a Windows API bug with the slim reader/writer (SRW) locks. It's just that the bug was discovered via std::shared_mutex as that is implemented using SRW locks. SRW locks: https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks https://learn.microsoft.com/en-us/windows/win32/sync/slim-re... Confirmation from a Microsoft employee that the bug has been raised internally with the Windows API team: https://old.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/kt3cndw/ https://old.reddit.com/r/cpp/comments/1b55686/maybe_possible...

dang 3y ago
Ok, I've changed the title to say that. Thanks!
tialaramex 3y ago
Yes, for example if you make a Rust std::sync:RWLock on Windows, it will literally be SRWLock because Microsoft advertises this API as having exactly the behaviour Rust wants so why would you build something worse instead ? Rust's Mutex on Windows is also an SRWLock but it can't hit this bug because it deliberately only uses the exclusive locking.
- iknowstuff 3y ago
  So it doesn't use a shared lock when .read() is used?
  - zozbot234 3y ago
    Rust has both Mutex and RWLock. The Mutex only uses exclusive locks, there's no distinction between "read" and "write".
    - iknowstuff 3y ago
      Oh sorry my morning brain thought the comment was all about RWLock