Understanding Mutex and Arc<Mutex<T>> in Rust: Thread-Safe Mutability

Building on Box, Rc, and Arc: Moving from shared ownership to shared mutable state

In my previous blog post, we explored Box, Rc, and Arc smart pointers for managing ownership and sharing data. But there was one crucial limitation: these smart pointers only provide immutable access to shared data. What if you need multiple parts of your program to modify the same data safely?

Enter Mutex<T> as Rust's solution for thread-safe mutable access to shared data.

The Problem: Shared Mutability

Let's start with the problem. With Arc<T>, we can share data across threads, but we can only read it:

use std::sync::Arc;
use std::thread;

fn main() {
    let shared_counter = Arc::new(0);
    let counter_clone = Arc::clone(&shared_counter);

    thread::spawn(move || {
        // This won't compile - Arc only gives immutable access
        // *counter_clone += 1;  // ERROR: cannot assign to data in an Arc
        println!("Counter value: {}", *counter_clone); // Reading is fine
    });
}

This is where Mutex<T> comes in.

What is Mutex?

Mutex<T> stands for "MUTual EXclusion." Think of it as a protective wrapper around your data that ensures only one thread can access the data at a time.

The Lock Mechanism

Unlike RefCell which uses runtime borrow checking (and panics on violations), Mutex uses an OS-level locking mechanism:

• When a thread wants to access the data, it must acquire the lock

• If the lock is available, the thread gets exclusive access

• If another thread already has the lock, the requesting thread blocks (waits) until the lock is released

• When the thread is done, the lock is automatically released

Basic Mutex Usage (Single-Threaded)

While Mutex is designed for multi-threading, let's first understand it in a single-threaded context:

use std::sync::Mutex;

fn main() {
    println!("Single-threaded Mutex example");

    // Create a mutex protecting a string
    let data = Mutex::new(String::from("Hello"));

    println!("Original data: {:?}", data.lock().unwrap());

    // Acquire lock and modify data
    {
        let mut locked_data = data.lock().unwrap(); // Get MutexGuard<String>
        locked_data.push_str(", World!");
        println!("Modified data: {}", *locked_data);

        // Lock automatically released when locked_data goes out of scope
    }

    // Can acquire lock again
    println!("Final data: {:?}", data.lock().unwrap());
}

Key concepts:

• data.lock() returns Result<MutexGuard<T>, PoisonError>

• MutexGuard<T> acts like &mut T - you can read and modify the data

• The lock is automatically released when the guard goes out of scope

• We use .unwrap() assuming the mutex isn't poisoned (more on this later)

The Power Combo: Arc<Mutex<T>>

For multi-threaded scenarios, we combine Arc (shared ownership) with Mutex (safe mutation):

use std::{sync::{Arc, Mutex}, thread, time::Duration};

fn main() {
    println!("Arc<Mutex<T>> shared mutable state");

    // Shared mutable data across threads
    let shared_data = Arc::new(Mutex::new(String::from("Ashwin")));

    // Vector to store thread handles
    let mut handles = vec![];

    // Spawn threads that will mutate shared data
    for i in 1..4 {
        let mutex_data = Arc::clone(&shared_data); // Each thread gets Arc clone

        let handle = thread::spawn(move || {
            // Acquire lock for exclusive access
            let mut data_in_thread = mutex_data.lock().unwrap();

            // Mutate the data safely
            data_in_thread.push_str(&format!(" (modified by thread {})", i));

            println!("Thread {} modified data: {}", i, *data_in_thread);

            // Simulate some work while holding the lock
            thread::sleep(Duration::from_millis(100));

            // Lock automatically released when data_in_thread drops
        });

        handles.push(handle);
    }

    // Wait for all threads to complete
    for handle in handles {
        handle.join().unwrap();
    }

    // Check final result with proper error handling
    match shared_data.lock() {
        Ok(data) => {
            println!("Final data: {}", *data);
        }
        Err(poisoned) => {
            println!("Mutex was poisoned, but data: {}", *poisoned.into_inner());
        }
    }
}

Why Mutex Instead of RefCell?

You might wonder: "Why not use Arc<RefCell<T>>?" Here's the crucial difference:

RefCell is designed for single-threaded use only. It uses regular (non-atomic) counters for borrow checking, which means multiple threads could corrupt the borrow state and cause race conditions. RefCell provides fast runtime borrow checking and allows multiple immutable borrows or one mutable borrow, but it panics if borrowing rules are violated.

Mutex is built for multi-threaded scenarios. It uses OS-level locking primitives that are thread-safe by design. Unlike RefCell which allows multiple readers, Mutex provides exclusive access only, meaning only one thread can access the data at any time. When borrowing rules would be violated, threads simply wait (block) instead of panicking.

The compiler prevents Arc<RefCell<T>> from compiling in multi-threaded contexts because RefCell is neither Send nor Sync, while Mutex is both Send and Sync, making it safe to share across thread boundaries.

// This won't compile - RefCell is not Send + Sync
let data = Arc::new(RefCell::new(42));
thread::spawn(move || {
    // ERROR: RefCell cannot be shared between threads safely
});

// This works - Mutex is Send + Sync
let data = Arc::new(Mutex::new(42));
thread::spawn(move || {
    *data.lock().unwrap() += 1; // Thread-safe mutation
});

Lock Poisoning and Error Handling

One unique aspect of Mutex is lock poisoning. If a thread panics while holding a lock, the mutex becomes "poisoned" to prevent data corruption:

// Try to use the mutex
match data.lock() {
    Ok(guard) => println!("Data: {:?}", *guard),
    Err(poisoned) => {
        println!("Mutex poisoned, but we can recover:");
        let guard = poisoned.into_inner();
        println!("Recovered data: {:?}", *guard);
    }
}

When to Use Mutex vs RefCell

Use Rc<RefCell<T>> when:

• Single-threaded application

• Need mutable shared state within a single thread

• Need multiple readers simultaneously

• Working with UI frameworks or single-threaded async runtimes

Use Arc<Mutex<T>> when:

• Multi-threaded application

• Sharing mutable state across threads

• Need thread-safe shared data access

The Complete Picture

Here's how all the smart pointers fit together:

// Single ownership, heap allocation
let data = Box::new(42);

// Multiple owners, immutable sharing (single-threaded)  
let data = Rc::new(42);

// Multiple owners, mutable sharing (single-threaded)
let data = Rc::new(RefCell::new(42));

// Multiple owners, immutable sharing (multi-threaded)
let data = Arc::new(42);

// Multiple owners, mutable sharing (multi-threaded) 
let data = Arc::new(Mutex::new(42)); // This is the ultimate combo!

Conclusion

Mutex<T> solves the final piece of the shared state puzzle in Rust. Combined with Arc, it gives you thread-safe shared mutable state, essential for building robust concurrent applications.

Mutex provides exclusive access through OS-level locking, Arc<Mutex<T>> enables thread-safe shared mutable state, and locks are automatically released when guards go out of scope. Always consider whether you need single-threaded (RefCell) or multi-threaded (Mutex) mutability, and handle lock poisoning gracefully in production code.

In the next post, we'll explore Semaphore for when you need controlled concurrent access rather than exclusive access.

All code examples are available at github.com/Ashwin-3cS/box-arc-rc-mutex-semaphore