Deadlock when upgrading an upgradable_read lock

[agourlay]

parking_lot version: 0.12.4
OS: ubuntu 25.04

I am observing deadlocks when mixing upgradable_read locks with read locks on different thread.

It appears that new read locks are preventing the upgradable lock from being upgraded which is surprising.

I would expect new read locks to be queued up for after the upgrade and release of the lock.

Here is the deadlock backtrace:

[2025-09-03T13:48:05.343Z ERROR parking_stress] 1 deadlocks detected
    Deadlock #0
    Thread Id 136378943760064
       0:     0x57db1ca81143 - parking_lot_core::parking_lot::deadlock_impl::on_unpark::he273ac1dd412a8c2
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot_core-0.9.11/src/parking_lot.rs:1211:32
       1:     0x57db1ca45cdb - parking_lot_core::parking_lot::deadlock::on_unpark::h2a1b2c41e9bbdca2
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot_core-0.9.11/src/parking_lot.rs:1144:9
       2:     0x57db1ca4482f - parking_lot_core::parking_lot::park::{{closure}}::hed3d5d78129fc2c3
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot_core-0.9.11/src/parking_lot.rs:637:17
       3:     0x57db1ca42c97 - parking_lot_core::parking_lot::with_thread_data::h441ed05b07c4f512
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot_core-0.9.11/src/parking_lot.rs:207:5
                               parking_lot_core::parking_lot::park::h0bbc060b0481a374
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot_core-0.9.11/src/parking_lot.rs:600:5
       4:     0x57db1ca4b04c - parking_lot::raw_rwlock::RawRwLock::wait_for_readers::h2c6fb81f052a6f7e
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot-0.12.4/src/raw_rwlock.rs:1022:17
       5:     0x57db1ca4a7ab - parking_lot::raw_rwlock::RawRwLock::upgrade_slow::h6c49c43caf111146
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot-0.12.4/src/raw_rwlock.rs:875:14
       6:     0x57db1c9fb8f0 - <parking_lot::raw_rwlock::RawRwLock as lock_api::rwlock::RawRwLockUpgrade>::upgrade::h1436c0376a214b1b
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/parking_lot-0.12.4/src/raw_rwlock.rs:374:31
       7:     0x57db1c9f5a9d - lock_api::rwlock::RwLockUpgradableReadGuard<R,T>::upgrade::hd8e23c93d41104ea
                                   at /home/agourlay/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lock_api-0.4.13/src/rwlock.rs:1946:26
       8:     0x57db1c9f7df6 - parking_stress::Shard::upgrade::h9188d2f3290b43fe

I have a self contained reproducer https://github.com/qdrant/parking-stress to make things clearer.

Just cargo run and it takes a few seconds to fail.

The weird part is that the deadlock only occurs when I enable the deadlock detector.

Hopefully you can answer my questions:

1. Am I using upgradable locks wrong?
2. Why does it seem like the deadlock detector is causing deadlocks?

Thanks for this great library!

[timvisee]

For what it's worth, disabling this loop in the deadlock detector seems to prevent triggering the deadlock:

parking_lot/core/src/parking_lot.rs

Lines 1362 to 1372 in 739d370

	for td in cycle {
	let bucket = lock_bucket((*td).key.load(Ordering::Relaxed));
	(*td).deadlock_data.deadlocked.set(true);
	*(*td).deadlock_data.backtrace_sender.get() = Some(sender.clone());
	let handle = (*td).parker.unpark_lock();
	// SAFETY: We hold the lock here, as required
	bucket.mutex.unlock();
	// unpark the deadlocked thread!
	// on unpark it'll notice the deadlocked flag and report back
	handle.unpark();
	}

[generall]

some observations from my side:

• deadlock happens if we check for deadlocks while requesting upgradable write access is happening

[2025-09-03T16:39:46.490Z INFO  parking_stress] 331 requesting read access
[2025-09-03T16:39:46.490Z INFO  parking_stress] 331 got read access (segments:33)
[2025-09-03T16:39:46.496Z INFO  parking_stress] 295 requesting upgradable write access
[2025-09-03T16:39:46.500Z INFO  parking_stress] Checking for deadlocks
[2025-09-03T16:39:46.508Z INFO  parking_stress] 332 requesting read access

• write loop is not required. Read + upgradable read are enough to repro

[Amanieu]

I think this might be a false positive in the deadlock detection code around upgradable locks. Calling deadlock_release and deadlock_acquire in upgrade_slow seems to avoid the issue.

[Amanieu]

    fn upgrade_slow(&self, timeout: Option<Instant>) -> bool {
        self.deadlock_release();
        let result = self.wait_for_readers(timeout, ONE_READER | UPGRADABLE_BIT);
        self.deadlock_acquire();
        result
    }

[timvisee]

Thanks! Applying your snippet fixes the issue for me, and it hasn't reproduced since.

Is it expected that a false positive in the detector hangs everything else? On detection, all pending locks fail to progress further. In this case it looks like the detector is introducing a deadlock.

[Amanieu]

I'm actually concerned that this may not be the correct solution since this can hide a deadlock where the current thread already holds a read lock while trying to upgrade. With this change the deadlock detector will not be able to detect this deadlock. I need to think about this some more.

[timvisee]

Thanks Amanieu! I'd love to help with this one, but my knowledge is definitely lacking here regarding all the fine details on locking.

For the time being we disabled the detector and/or applied this fix in our code base.

Thanks for the fantastic project! 🙌