This crate provides spin-based versions of the
std::lazy. Because synchronization is done through spinning,
the primitives are suitable for use in
Guards can be sent and shared between threads
Different strategies for dealing with contention
spin is not a drop-in replacement for
should not be considered as such)
an effort is made to keep this crate reasonably consistent with
Many of the types defined in this crate have ‘additional capabilities’ when compared to
Guards support leaking.
Onceowns the value returned by its
RwLocksupports counting readers and writers.
Conversely, the types in this crate do not have some of the features
- Locks do not track panic poisoning.
The crate comes with a few feature flags that you may wish to use.
lock_apienables support for
ticket_mutexuses a ticket lock for the implementation of
fair_mutexenables a fairer implementation of
Mutexthat uses eventual fairness to avoid starvation
stdenables support for thread yielding instead of spinning
pub use mutex::MutexGuard;
pub use relax::Yield;
pub use relax::RelaxStrategy;
pub use relax::Spin;
pub use rwlock::RwLockReadGuard;
barrierSynchronization primitive allowing multiple threads to synchronize the beginning of some computation.
lazySynchronization primitives for lazy evaluation.
lock_apiSpin synchronisation primitives, but compatible with
mutexLocks that have the same behaviour as a mutex.
onceSynchronization primitives for one-time evaluation.
- Strategies that determine the behaviour of locks when encountering contention.
rwlockA lock that provides data access to either one writer or many readers.
barrierA primitive that synchronizes the execution of multiple threads. See
lazyA value which is initialized on the first access. See
mutexA primitive that synchronizes the execution of multiple threads. See
onceA primitive that provides lazy one-time initialization. See
rwlockA lock that provides data access to either one writer or many readers. See
rwlockA guard that provides mutable data access. See