Refuse recursive read locks in lockorder testing
authorMatt Corallo <git@bluematt.me>
Thu, 2 Feb 2023 22:38:54 +0000 (22:38 +0000)
committerMatt Corallo <git@bluematt.me>
Tue, 28 Feb 2023 01:06:35 +0000 (01:06 +0000)
commit9c08fbd435b097c0aeec2843d8b4a6fdec06a8f0
tree0f1268c7aca56de81b3d88ad6418b3b8fccb712a
parent2c8a26c6d23bb224d61b8fe605f961b3d08def87
Refuse recursive read locks in lockorder testing

Our existing lockorder tests assume that a read lock on a thread
that is already holding the same read lock is totally fine. This
isn't at all true. The `std` `RwLock` behavior is
platform-dependent - on most platforms readers can starve writers
as readers will never block for a pending writer. However, on
platforms where this is not the case, one thread trying to take a
write lock may deadlock with another thread that both already has,
and is attempting to take again, a read lock.

Worse, our in-tree `FairRwLock` exhibits this behavior explicitly
on all platforms to avoid the starvation issue.

Thus, we shouldn't have any special handling for allowing recursive
read locks, so we simply remove it here.
lightning/src/ln/chanmon_update_fail_tests.rs
lightning/src/ln/functional_test_utils.rs
lightning/src/ln/payment_tests.rs
lightning/src/routing/utxo.rs
lightning/src/sync/debug_sync.rs
lightning/src/sync/test_lockorder_checks.rs