Struct MappedMutexGuard

Source

pub struct MappedMutexGuard<'a, R: RawMutex, T: ?Sized> { /* private fields */ }

Expand description

An RAII mutex guard returned by MutexGuard::map, which can point to a subfield of the protected data.

The main difference between MappedMutexGuard and MutexGuard is that the former doesn’t support temporarily unlocking and re-locking, since that could introduce soundness issues if the locked object is modified by another thread.

Implementations§

Source §

impl<'a, R: RawMutex + 'a, T: ?Sized + 'a> MappedMutexGuard<'a, R, T>

Source

pub fn map<U: ?Sized, F>(s: Self, f: F) -> MappedMutexGuard<'a, R, U>
where F: FnOnce(&mut T) -> &mut U,

Makes a new MappedMutexGuard for a component of the locked data.

This operation cannot fail as the MappedMutexGuard passed in already locked the mutex.

This is an associated function that needs to be used as MappedMutexGuard::map(...). A method would interfere with methods of the same name on the contents of the locked data.

Source

pub fn try_map<U: ?Sized, F>( s: Self, f: F, ) -> Result<MappedMutexGuard<'a, R, U>, Self>
where F: FnOnce(&mut T) -> Option<&mut U>,

Attempts to make a new MappedMutexGuard for a component of the locked data. The original guard is returned if the closure returns None.

This operation cannot fail as the MappedMutexGuard passed in already locked the mutex.

This is an associated function that needs to be used as MappedMutexGuard::try_map(...). A method would interfere with methods of the same name on the contents of the locked data.

Source §

impl<'a, R: RawMutexFair + 'a, T: ?Sized + 'a> MappedMutexGuard<'a, R, T>

Source

pub fn unlock_fair(s: Self)

Unlocks the mutex using a fair unlock protocol.

By default, mutexes are unfair and allow the current thread to re-lock the mutex before another has the chance to acquire the lock, even if that thread has been blocked on the mutex for a long time. This is the default because it allows much higher throughput as it avoids forcing a context switch on every mutex unlock. This can result in one thread acquiring a mutex many more times than other threads.

However in some cases it can be beneficial to ensure fairness by forcing the lock to pass on to a waiting thread if there is one. This is done by using this method instead of dropping the MutexGuard normally.