Feature gate: #![feature(reentrant_lock)]

This is a tracking issue for ReentrantLock, a re-entrant lock useful for avoiding a common type of deadlocks.

Public API

// std::sync

pub struct ReentrantLock<T: ?Sized> {}
pub struct ReentrantLockGuard<'a, T: ?Sized + 'a> {}

impl<T> ReentrantLock<T> {
    pub const fn new(t: T) -> ReentrantLock<T>;
    pub fn into_inner(self) -> T;
}

impl<T: ?Sized> ReentrantLock<T> {
    pub fn lock(&self) -> ReentrantLockGuard<'_, T>;
    pub fn get_mut(&mut self) -> &mut T;
}

impl<T: Send + ?Sized> Send for ReentrantLock<T> {}
impl<T: Send + ?Sized> Sync for ReentrantLock<T> {}

impl<T: ?Sized> !Send for ReentrantLockGuard<'_, T> {}
impl<T: ?Sized + Sync> Sync for ReentrantLockGuard<'_, T> {}

impl<T: UnwindSafe + ?Sized> UnwindSafe for ReentrantLock<T> {}
impl<T: RefUnwindSafe + ?Sized> RefUnwindSafe for ReentrantLock<T> {}

impl<T: Default> Default for ReentrantLock<T> {}
impl<T> From<T> for ReentrantLock<T> {}

impl<T: ?Sized> Deref for ReentrantLockGuard<'_, T> {
    type Target = T;
}

impl<T: Debug + ?Sized> Debug for ReentrantLock<T> {}
impl<T: Debug + ?Sized> Debug for ReentrantLockGuard<'_, T> {}
impl<T: Display + ?Sized> Display for ReentrantLockGuard<'_, T> {}

Steps / History

• ACP: Add sync::ReentrantLock libs-team#193
• Implementation:
  • Make ReentrantLock public #110543
  • Add manual Sync impl for ReentrantLockGuard #125527
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

Poisoning

I would argue that ReentrantLock should not implement lock poisoning. Since it only provides shared access, breaking the invariants of the inner type is something that the lock has no control over, as it requires interior mutability. It would make sense to require that T: RefUnwindSafe, but I think that is too inconvenient for now. If RefUnwindSafe were a lint trait, it should definitely be used.

Fallible locking

Is there a need for fallible locking, even if it cannot fail because of reentrancy? How would this look like, considering that TryLockResult also has a poisoning case, which would never be used here?

Naming

New synchronization primitives like OnceLock have used the Lock suffix. IMHO the name ReentrantLock rhymes well with the other types and is more consistent, but ReentrantMutex better highlights the similarity to Mutex.