4 ms·
These things are often tricky to reproduce, but the deadlock should happen from the spec, right? Essentially, a pending write lock should block new read locks f
by codeflo 5y ago
These things are often tricky to reproduce, but the deadlock should happen from the spec, right? Essentially, a pending write lock should block new read locks from being acquired -- this is a feature, if it didn't do that, the write lock would starve -- so if you try to acquire the second read lock while the write lock is pending, you get a deadlock.
- masklinn 5y ago> These things are often tricky to reproduce, but the deadlock should happen from the spec, right? Pretty sure the spec is entirely silent on the subject. > Essentially, a pending write lock should block new read locks from being acquired -- this is a feature, if it didn't do that That is an implementation detail of the lock. I don’t think either POSIX specifies the bias of its rwlock, and Rust explicitly documents that it does not and delegates to the OS. Plenty of RWLock will, in fact, starve writers under heavy contention (both read-bias and write-bias have their pros and cons).
- codeflo 5y agoYou’re right, I misremembered this completely, that’s very good to know. I’ve recently mostly used parking_lot, which guarantees prioritizing writers. That’s also the behavior where the post I replied to wondered if parking_lot was missing a check — in fact no, it has an additional feature.