Tracking Issue for lock_value_accessors

[EFanZh]

Feature gate: #![feature(lock_value_accessors)]

This is a tracking issue for feature lock_value_accessors.

Public API

impl<T> Mutex<T> {
    pub fn get_cloned(&self) -> Result<T, PoisonError<()>> where T: Clone { ... }
    pub fn set(&self, value: T) -> Result<(), PoisonError<T>> { ... }
    pub fn replace(&self, value: T) -> LockResult<T> { ... }
}

impl<T> RwLock<T> {
    pub fn get_cloned(&self) -> Result<T, PoisonError<()>> where T: Clone { ... }
    pub fn set(&self, value: T) -> Result<(), PoisonError<T>> { ... }
    pub fn replace(&self, value: T) -> LockResult<T> { ... }
}

Steps / History

• ACP: Add get, set and replace methods to Mutex and RwLock libs-team#485
• Implementation: Add value accessor methods to Mutex and RwLock #133406
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Whether we should checking poisoning first and avoid unnecessary lock acquire attempts.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Noratrieb]

I think the name get is too generic and "default", it makes you think that this is what you usually want, even if it is often not (as it clones). Certainly a useful method, but I think the clone should be more explicit in the name, I'd suggest get_cloned (maybe someone else has a better name).

[EFanZh]

I am OK with get_cloned.

[marmeladema]

Would it make sense to have a get_copied()?

Or even a get_with which accepts a closure to retrieve the return value? This could cover clone and copy types as well as allow to return a value from a nested field like mutex.get_with(|val| val.field.clone())

[EFanZh]

@marmeladema: I am in favor of adding a set of more generalized APIs:

impl<T> Mutex<T>
where
    T: ?Sized,
{
    pub fn with_mut<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
    where
        F: FnOnce(&mut T) -> R,
    {
        match self.lock() {
            Ok(mut guard) => Ok(f(&mut guard)),
            Err(_) => Err(PoisonError::new(f)),
        }
    }
}

impl<T> RwLock<T>
where
    T: ?Sized,
{
    pub fn with<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
    where
        F: FnOnce(&T) -> R,
    {
        match self.read() {
            Ok(guard) => Ok(f(&guard)),
            Err(_) => Err(PoisonError::new(f)),
        }
    }

    pub fn with_mut<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
    where
        F: FnOnce(&mut T) -> R,
    {
        match self.write() {
            Ok(mut guard) => Ok(f(&mut guard)),
            Err(_) => Err(PoisonError::new(f)),
        }
    }
}

These new APIs have the advantage of being explicit about locking scopes. Traditional APIs rely on the destructing of lock guard objects, which is not visually apparent to users, increasing the risk of locks being held for longer than necessary. With the new APIs, the chances of unintentionally holding locks for extended periods can be reduced.

A new ACP has been accepted for non-poisoning types: rust-lang/libs-team#497.