`RwLock` can sometimes deadlock on Windows with only read locks holding or waiting for the lock

[SkiFire13]

I tried this code:

use std::sync::{Barrier, RwLock};

fn main() {
    for i in 0.. {
        let lock = RwLock::new(());

        let barrier = Barrier::new(5);
        let write_guard = lock.write();

        std::thread::scope(|s| {
            for _ in 0..5 {
                s.spawn(|| {
                    let read_guard = lock.read();
                    barrier.wait();
                    drop(read_guard);
                });
            }

            drop(write_guard);
        });

        println!("{i}");
    }
}

I expected to see this happen: the program continues to print increasing numbers, never stopping.

Instead, this happened: it stop after a non-deterministic amount of numbers printed, usually less than 1000.

The example is adapted from this C++ thread https://www.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/
According to some comments it seems to be a bug in Windows' SRWLOCK which Rust appears to use for RwLock.

Opened as requested on zulip https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/SRWLOCK.20bug/near/424539022

Meta

rustc --version --verbose:

rustc 1.76.0 (07dca489a 2024-02-04)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-pc-windows-msvc
release: 1.76.0
LLVM version: 17.0.6

[ChrisDenton]

As it happens, I was investigating switching to the WaitOnAddress APIs. This provides a very good motivation for me to prioritise it.

@rustbot claim