Struct Mutex

pub struct Mutex<T: ?Sized> { /* private fields */ }

A mutual exclusion primitive useful for protecting shared data

This mutex will block threads waiting for the lock to become available. The mutex can be created via a new constructor. Each mutex has a type parameter which represents the data that it is protecting. The data can only be accessed through the RAII guards returned from lock and try_lock, which guarantees that the data is only ever accessed when the mutex is locked.

Poisoning

This implementation of the mutex does not implement poisoning, as it might not be possible to do in a no_std environment. This puts the responsibility of never tainting the held data on the user of the mutex.

Examples

use sync_linux_no_libc::sync::Mutex;
use std::sync::{Arc};
use std::thread;
use std::sync::mpsc::channel;

const N: usize = 10;

// Spawn a few threads to increment a shared variable (non-atomically), and
// let the main thread know once all increments are done.
//
// Here we're using an Arc to share memory among threads, and the data inside
// the Arc is protected with a mutex.
let data = Arc::new(Mutex::new(0));

let (tx, rx) = channel();
for _ in 0..N {
    let (data, tx) = (Arc::clone(&data), tx.clone());
    thread::spawn(move || {
        // The shared state can only be accessed once the lock is held.
        // Our non-atomic increment is safe because we're the only thread
        // which can access the shared state when the lock is held.
        //
        // We unwrap() the return value to assert that we are not expecting
        // threads to ever fail while holding the lock.
        let mut data = data.lock();
        *data += 1;
        if *data == N {
            tx.send(()).unwrap();
        }
        // the lock is unlocked here when `data` goes out of scope.
    });
}

rx.recv().unwrap();

To unlock a mutex guard sooner than the end of the enclosing scope, either create an inner scope or drop the guard manually.

use sync_linux_no_libc::sync::Mutex;
use std::sync::{Arc};
use std::thread;

const N: usize = 3;

let data_mutex = Arc::new(Mutex::new(vec![1, 2, 3, 4]));
let res_mutex = Arc::new(Mutex::new(0));

let mut threads = Vec::with_capacity(N);
(0..N).for_each(|_| {
    let data_mutex_clone = Arc::clone(&data_mutex);
    let res_mutex_clone = Arc::clone(&res_mutex);

    threads.push(thread::spawn(move || {
        // Here we use a block to limit the lifetime of the lock guard.
        let result = {
            let mut data = data_mutex_clone.lock();
            // This is the result of some important and long-ish work.
            let result = data.iter().fold(0, |acc, x| acc + x * 2);
            data.push(result);
            result
            // The mutex guard gets dropped here, together with any other values
            // created in the critical section.
        };
        // The guard created here is a temporary dropped at the end of the statement, i.e.
        // the lock would not remain being held even if the thread did some additional work.
        *res_mutex_clone.lock() += result;
    }));
});

let mut data = data_mutex.lock();
// This is the result of some important and long-ish work.
let result = data.iter().fold(0, |acc, x| acc + x * 2);
data.push(result);
// We drop the `data` explicitly because it's not necessary anymore and the
// thread still has work to do. This allows other threads to start working on
// the data immediately, without waiting for the rest of the unrelated work
// to be done here.
//
// It's even more important here than in the threads because we `.join` the
// threads after that. If we had not dropped the mutex guard, a thread could
// be waiting forever for it, causing a deadlock.
// As in the threads, a block could have been used instead of calling the
// `drop` function.
drop(data);
// Here the mutex guard is not assigned to a variable and so, even if the
// scope does not end after this line, the mutex is still released: there is
// no deadlock.
*res_mutex.lock() += result;

threads.into_iter().for_each(|thread| {
    thread
        .join()
        .expect("The thread creating or execution failed !")
});

assert_eq!(*res_mutex.lock(), 800);

Implementations

impl<T> Mutex<T>

pub const fn new(t: T) -> Mutex<T>

Creates a new mutex in an unlocked state ready for use.

Examples

use sync_linux_no_libc::sync::Mutex;

let mutex = Mutex::new(0);

impl<T: ?Sized> Mutex<T>

pub fn lock(&self) -> MutexGuard<'_, T>

Acquires a mutex, blocking the current thread until it is able to do so.

This function will block the local thread until it is available to acquire the mutex. Upon returning, the thread is the only thread with the lock held. An RAII guard is returned to allow scoped unlock of the lock. When the guard goes out of scope, the mutex will be unlocked.

The exact behavior on locking a mutex in the thread which already holds the lock is left unspecified. However, this function will not return on the second call (it might panic or deadlock, for example).

Panics

This function might panic when called if the lock is already held by the current thread.

Examples

use sync_linux_no_libc::sync::Mutex;
use std::sync::{Arc};
use std::thread;

let mutex = Arc::new(Mutex::new(0));
let c_mutex = Arc::clone(&mutex);

thread::spawn(move || {
    *c_mutex.lock() = 10;
}).join().expect("thread::spawn failed");
assert_eq!(*mutex.lock(), 10);

pub fn try_lock(&self) -> TryLockResult<MutexGuard<'_, T>>

Attempts to acquire this lock.

If the lock could not be acquired at this time, then Err is returned. Otherwise, an RAII guard is returned. The lock will be unlocked when the guard is dropped.

This function does not block.

Errors

If the mutex could not be acquired because it is already locked, then this call will return the WouldBlock error.

Examples

use sync_linux_no_libc::sync::Mutex;
use std::sync::{Arc};
use std::thread;

let mutex = Arc::new(Mutex::new(0));
let c_mutex = Arc::clone(&mutex);

thread::spawn(move || {
    let mut lock = c_mutex.try_lock();
    if let Ok(ref mut mutex) = lock {
        **mutex = 10;
    } else {
        println!("try_lock failed");
    }
}).join().expect("thread::spawn failed");
assert_eq!(*mutex.lock(), 10);

pub fn into_inner(self) -> T

where T: Sized,

Consumes this mutex, returning the underlying data.

Examples

use sync_linux_no_libc::sync::Mutex;

let mutex = Mutex::new(0);
assert_eq!(mutex.into_inner(), 0);

pub fn get_mut(&mut self) -> &mut T

Returns a mutable reference to the underlying data.

Since this call borrows the Mutex mutably, no actual locking needs to take place – the mutable borrow statically guarantees no new locks can be acquired while this reference exists. Note that this method does not clear any previous abandoned locks (e.g., via forget() on a MutexGuard).

Examples

use sync_linux_no_libc::sync::Mutex;

let mut mutex = Mutex::new(0);
*mutex.get_mut() = 10;
assert_eq!(*mutex.lock(), 10);

Trait Implementations

impl<T: ?Sized + Debug> Debug for Mutex<T>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<T: ?Sized + Default> Default for Mutex<T>

fn default() -> Mutex<T>

Creates a Mutex<T>, with the Default value for T.

impl<T> From<T> for Mutex<T>

fn from(t: T) -> Self

Creates a new mutex in an unlocked state ready for use. This is equivalent to Mutex::new.

impl<T: ?Sized + Send> Send for Mutex<T>

T must be Send for a Mutex to be Send because it is possible to acquire the owned T from the Mutex via into_inner.

impl<T: ?Sized + Send> Sync for Mutex<T>

T must be Send for Mutex to be Sync. This ensures that the protected data can be accessed safely from multiple threads without causing data races or other unsafe behavior.

Mutex<T> provides mutable access to T to one thread at a time. However, it’s essential for T to be Send because it’s not safe for non-Send structures to be accessed in this manner. For instance, consider Rc, a non-atomic reference counted smart pointer, which is not Send. With Rc, we can have multiple copies pointing to the same heap allocation with a non-atomic reference count. If we were to use Mutex<Rc<_>>, it would only protect one instance of Rc from shared access, leaving other copies vulnerable to potential data races.

Also note that it is not necessary for T to be Sync as &T is only made available to one thread at a time if T is not Sync.