Skip to content

Commit e38b3eb

Browse files
authored
Rollup merge of rust-lang#82596 - matklad:rwlock, r=sfackler
clarify RW lock's priority gotcha In particular, the following program works on Linux, but deadlocks on mac: ```rust use std::{ sync::{Arc, RwLock}, thread, time::Duration, }; fn main() { let lock = Arc::new(RwLock::new(())); let r1 = thread::spawn({ let lock = Arc::clone(&lock); move || { let _rg = lock.read(); eprintln!("r1/1"); sleep(1000); let _rg = lock.read(); eprintln!("r1/2"); sleep(5000); } }); sleep(100); let w = thread::spawn({ let lock = Arc::clone(&lock); move || { let _wg = lock.write(); eprintln!("w"); } }); sleep(100); let r2 = thread::spawn({ let lock = Arc::clone(&lock); move || { let _rg = lock.read(); eprintln!("r2"); sleep(2000); } }); r1.join().unwrap(); r2.join().unwrap(); w.join().unwrap(); } fn sleep(ms: u64) { std::thread::sleep(Duration::from_millis(ms)) } ``` Context: I was completely mystified by a my CI deadlocking on mac ([here](matklad/xshell#7)), until ``@azdavis`` debugged the issue. See a stand-alone reproduciton here: matklad/xshell#15
2 parents a70be0b + 261c952 commit e38b3eb

File tree

1 file changed

+3
-1
lines changed

1 file changed

+3
-1
lines changed

library/std/src/sync/rwlock.rs

+3-1
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,9 @@ use crate::sys_common::rwlock as sys;
2323
///
2424
/// The priority policy of the lock is dependent on the underlying operating
2525
/// system's implementation, and this type does not guarantee that any
26-
/// particular policy will be used.
26+
/// particular policy will be used. In particular, a writer which is waiting to
27+
/// acquire the lock in `write` might or might not block concurrent calls to
28+
/// `read`.
2729
///
2830
/// The type parameter `T` represents the data that this lock protects. It is
2931
/// required that `T` satisfies [`Send`] to be shared across threads and

0 commit comments

Comments
 (0)