Struct lock_api::MappedMutexGuard
source · [−]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
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.
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.
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.