Trait mycelium_util::sync::blocking::ScopedRawMutex

pub unsafe trait ScopedRawMutex {
    // Required methods
    fn try_with_lock<R>(&self, f: impl FnOnce() -> R) -> Option<R>;
    fn with_lock<R>(&self, f: impl FnOnce() -> R) -> R;
    fn is_locked(&self) -> bool;
}
Expand description

Raw scoped mutex trait.

This mutex is “raw”, which means it does not actually contain the protected data, it just implements the mutex mechanism. For most uses you should use BlockingMutex from the scoped-mutex-impls crate instead, which is generic over a ScopedRawMutex and contains the protected data.

Safety

ScopedRawMutex implementations must ensure that, while locked, no other thread can lock the RawMutex concurrently. This can usually be implemented using an AtomicBool to track the “taken” state. See the scoped-mutex-impls crate for examples of correct implementations.

Unsafe code is allowed to rely on this fact, so incorrect implementations will cause undefined behavior.

Required Methods§

fn try_with_lock<R>(&self, f: impl FnOnce() -> R) -> Option<R>

Lock this ScopedRawMutex, calling f() after the lock has been acquired, and releasing the lock after the completion of f().

If this was successful, Some(R) will be returned. If the mutex was already locked, None will be returned

fn with_lock<R>(&self, f: impl FnOnce() -> R) -> R

Lock this ScopedRawMutex, calling f() after the lock has been acquired, and releasing the lock after the completion of f().

Implementors may choose whether to block or panic if the lock is already locked. It is recommended to panic if it is possible to know that deadlock has occurred.

For implementations on a system with threads, blocking may be the correct choice.

For implementations where a single thread is present, panicking immediately may be the correct choice.

fn is_locked(&self) -> bool

Is this mutex currently locked?

Object Safety§

This trait is not object safe.

Implementors§