What are the trade-offs between `Arc<Mutex<T>>` and `Arc<RwLock<T>>` for shared mutable state?

Arc<Mutex<T>> provides exclusive access to the inner value, allowing only one thread to hold the lock at a time regardless of operation type. Arc<RwLock<T>> allows multiple concurrent readers or one exclusive writer, providing better throughput for read-heavy workloads but with higher per-operation overhead. The choice depends on the ratio of reads to writes, contention patterns, and whether the lock coordination overhead of RwLock is justified by the concurrency gains. Mutex is simpler and has lower overhead; RwLock enables parallel reads at the cost of more complex internal state management.

Basic Mutex Usage

use std::sync::{Arc, Mutex};
use std::thread;
 
fn main() {
    let data = Arc::new(Mutex::new(vec![1, 2, 3]));
    
    let mut handles = vec![];
    
    for i in 0..3 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let mut guard = data.lock().unwrap();
            guard.push(i);
        }));
    }
    
    for handle in handles {
        handle.join().unwrap();
    }
    
    println!("{:?}", *data.lock().unwrap());
}

Mutex provides exclusive access: only one thread can hold the lock.

Basic RwLock Usage

use std::sync::{Arc, RwLock};
use std::thread;
 
fn main() {
    let data = Arc::new(RwLock::new(vec![1, 2, 3]));
    
    let mut handles = vec![];
    
    // Multiple readers can hold lock simultaneously
    for _ in 0..3 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let guard = data.read().unwrap();
            println!("Reader sees: {:?}", *guard);
        }));
    }
    
    // Writer needs exclusive access
    let data_write = Arc::clone(&data);
    handles.push(thread::spawn(move || {
        let mut guard = data_write.write().unwrap();
        guard.push(4);
    }));
    
    for handle in handles {
        handle.join().unwrap();
    }
}

RwLock allows concurrent readers but exclusive writers.

Concurrent Reader Demonstration

use std::sync::{Arc, RwLock};
use std::thread;
use std::time::Instant;
 
fn main() {
    let data = Arc::new(RwLock::new(vec![0u64; 1_000_000]));
    let start = Instant::now();
    
    // Multiple concurrent readers
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let guard = data.read().unwrap();
            guard.iter().sum::<u64>()
        }));
    }
    
    let results: Vec<_> = handles.into_iter()
        .map(|h| h.join().unwrap())
        .collect();
    
    println!("RwLock concurrent readers: {:?}", start.elapsed());
    println!("Results: {:?}", results);
}

All readers execute concurrently with RwLock.

Mutex Blocks All Operations

use std::sync::{Arc, Mutex};
use std::thread;
use std::time::Instant;
 
fn main() {
    let data = Arc::new(Mutex::new(vec![0u64; 1_000_000]));
    let start = Instant::now();
    
    // Readers execute one at a time
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let guard = data.lock().unwrap();
            guard.iter().sum::<u64>()
        }));
    }
    
    let results: Vec<_> = handles.into_iter()
        .map(|h| h.join().unwrap())
        .collect();
    
    println!("Mutex readers: {:?}", start.elapsed());
}

Readers execute sequentially with Mutex.

Read-Heavy Workload Performance

use std::sync::{Arc, Mutex, RwLock};
use std::thread;
use std::time::Instant;
 
fn main() {
    // 95% reads, 5% writes
    let iterations = 100_000;
    let read_ratio = 0.95;
    
    // Mutex benchmark
    let mutex_data = Arc::new(Mutex::new(vec![0u64; 10_000]));
    let start = Instant::now();
    
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&mutex_data);
        handles.push(thread::spawn(move || {
            for i in 0..iterations {
                if (i as f64 / iterations as f64) < read_ratio {
                    let guard = data.lock().unwrap();
                    let _ = guard.len();
                } else {
                    let mut guard = data.lock().unwrap();
                    guard[0] += 1;
                }
            }
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    let mutex_time = start.elapsed();
    
    // RwLock benchmark
    let rwlock_data = Arc::new(RwLock::new(vec![0u64; 10_000]));
    let start = Instant::now();
    
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&rwlock_data);
        handles.push(thread::spawn(move || {
            for i in 0..iterations {
                if (i as f64 / iterations as f64) < read_ratio {
                    let guard = data.read().unwrap();
                    let _ = guard.len();
                } else {
                    let mut guard = data.write().unwrap();
                    guard[0] += 1;
                }
            }
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    let rwlock_time = start.elapsed();
    
    println!("Read-heavy Mutex: {:?}", mutex_time);
    println!("Read-heavy RwLock: {:?}", rwlock_time);
    // RwLock typically faster for read-heavy workloads
}

Concurrent reads provide throughput gains when reads dominate.

Write-Heavy Workload Performance

use std::sync::{Arc, Mutex, RwLock};
use std::thread;
use std::time::Instant;
 
fn main() {
    // 90% writes, 10% reads
    let iterations = 100_000;
    let write_ratio = 0.90;
    
    // Mutex benchmark
    let mutex_data = Arc::new(Mutex::new(0u64));
    let start = Instant::now();
    
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&mutex_data);
        handles.push(thread::spawn(move || {
            for i in 0..iterations {
                if (i as f64 / iterations as f64) < write_ratio {
                    let mut guard = data.lock().unwrap();
                    *guard += 1;
                } else {
                    let guard = data.lock().unwrap();
                    let _ = *guard;
                }
            }
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    let mutex_time = start.elapsed();
    
    // RwLock benchmark
    let rwlock_data = Arc::new(RwLock::new(0u64));
    let start = Instant::now();
    
    let mut handles = vec![];
    for _ in 0..4 {
        let data = Arc::clone(&rwlock_data);
        handles.push(thread::spawn(move || {
            for i in 0..iterations {
                if (i as f64 / iterations as f64) < write_ratio {
                    let mut guard = data.write().unwrap();
                    *guard += 1;
                } else {
                    let guard = data.read().unwrap();
                    let _ = *guard;
                }
            }
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    let rwlock_time = start.elapsed();
    
    println!("Write-heavy Mutex: {:?}", mutex_time);
    println!("Write-heavy RwLock: {:?}", rwlock_time);
    // Mutex often faster for write-heavy: lower overhead
}

When writes dominate, RwLock overhead outweighs concurrency benefits.

RwLock Internal Structure

use std::sync::RwLock;
 
fn main() {
    // RwLock has more internal state than Mutex:
    // - Reader count (number of active readers)
    // - Writer waiting flag/queue
    // - Fairness mechanism (potentially)
    
    // This overhead exists for every lock/unlock operation
    let lock = RwLock::new(42);
    
    // Read lock increments reader count
    {
        let _guard1 = lock.read().unwrap();  // reader_count = 1
        let _guard2 = lock.read().unwrap();  // reader_count = 2
        // Both hold lock simultaneously
    }  // Guards dropped, reader_count = 0
    
    // Write lock checks: no readers, no writers
    {
        let mut guard = lock.write().unwrap();  // writer active
        *guard += 1;
    }
}

RwLock tracks reader count and writer state, adding overhead.

Mutex Internal Structure

use std::sync::Mutex;
 
fn main() {
    // Mutex has minimal internal state:
    // - Locked/unlocked flag
    // - Possibly a waiter queue
    
    let lock = Mutex::new(42);
    
    // Lock: check flag, set to locked, proceed
    {
        let guard = lock.lock().unwrap();
        // No need to track reader count
    }
    // Unlock: clear flag, wake waiters
}

Mutex has simpler state management with lower overhead.

Writer Starvation in RwLock

use std::sync::{Arc, RwLock};
use std::thread;
 
fn main() {
    let data = Arc::new(RwLock::new(0));
    
    // Continuous readers can starve writers
    let reader_handles: Vec<_> = (0..3)
        .map(|i| {
            let data = Arc::clone(&data);
            thread::spawn(move || {
                for _ in 0..1_000_000 {
                    if let Ok(guard) = data.read() {
                        let _ = *guard;
                    }
                }
                println!("Reader {} done", i);
            })
        })
        .collect();
    
    // Writer may struggle to acquire
    let writer = {
        let data = Arc::clone(&data);
        thread::spawn(move || {
            for _ in 0..10 {
                if let Ok(mut guard) = data.write() {
                    *guard += 1;
                }
            }
            println!("Writer done");
        })
    };
    
    for h in reader_handles {
        h.join().unwrap();
    }
    writer.join().unwrap();
}

Continuous readers can prevent writers from acquiring the lock.

Fair RwLock Behavior

use std::sync::{Arc, RwLock};
 
fn main() {
    // std::sync::RwLock behavior depends on platform:
    // - Some implementations are writer-preferring (fair to writers)
    // - Some are reader-preferring (may starve writers)
    
    // RwLock is NOT fair by default in many implementations
    // A steady stream of readers can indefinitely delay writers
    
    // Mitigation strategies:
    // 1. Keep read locks short
    // 2. Use Mutex when writes are important
    // 3. Consider parking_lot::RwLock for more control
    
    let lock = RwLock::new(42);
    
    // Short read lock duration reduces writer starvation
    {
        let guard = lock.read().unwrap();
        let value = *guard;
        // Immediately drop guard
    }
}

Writer starvation depends on implementation and lock hold time.

Poisoning Behavior

use std::sync::{Arc, Mutex, RwLock};
use std::thread;
 
fn main() {
    // Both Mutex and RwLock can become poisoned
    
    // Mutex poisoning
    let mutex = Arc::new(Mutex::new(42));
    let mutex_clone = Arc::clone(&mutex);
    
    let handle = thread::spawn(move || {
        let mut guard = mutex_clone.lock().unwrap();
        *guard += 1;
        panic!("Panic while holding mutex");  // Poison the mutex
    });
    
    handle.join().unwrap_err();
    
    // Now the mutex is poisoned
    match mutex.lock() {
        Ok(_) => println!("Got lock"),
        Err(poison_err) => {
            // Can still access the data via into_inner()
            let value = poison_err.into_inner();
            println!("Mutex poisoned, recovered value: {}", *value);
        }
    }
    
    // RwLock works similarly for poisoning
}

Both Mutex and RwLock can become poisoned on panic.

Poisoning Recovery

use std::sync::{Arc, Mutex};
 
fn main() {
    let mutex = Arc::new(Mutex::new(vec![1, 2, 3]));
    
    // Option 1: Recover and continue
    let guard = mutex.lock().unwrap_or_else(|poison_err| {
        println!("Mutex poisoned, recovering");
        poison_err.into_inner()
    });
    
    // Option 2: Ignore poisoning entirely
    let mutex2 = Arc::new(Mutex::new(42));
    // Set poisoning behavior to ignore
    // (requires parking_lot or similar crate)
}

Poisoning can be handled or recovered from.

Read Guard vs Write Guard

use std::sync::RwLock;
 
fn main() {
    let lock = RwLock::new(vec![1, 2, 3]);
    
    // Read guard: shared reference, read-only
    {
        let guard1 = lock.read().unwrap();
        let guard2 = lock.read().unwrap();  // OK: multiple readers
        
        println!("Reader 1: {:?}", *guard1);
        println!("Reader 2: {:?}", *guard2);
        // Cannot modify through read guard
        // guard1.push(4);  // Compile error
    }
    
    // Write guard: exclusive reference, mutable
    {
        let mut guard = lock.write().unwrap();
        guard.push(4);  // OK: exclusive access
        println!("Writer: {:?}", *guard);
    }
    
    // Cannot hold read and write simultaneously
    // let read_guard = lock.read().unwrap();
    // let write_guard = lock.write().unwrap();  // Blocks forever
}

Read guards provide shared access; write guards provide exclusive access.

Downgrading Write Lock

use std::sync::RwLock;
 
fn main() {
    let lock = RwLock::new(vec![1, 2, 3]);
    
    // Acquire write lock
    let write_guard = lock.write().unwrap();
    
    // Modify while holding write lock
    // ...make changes...
    
    // std::sync::RwLock supports downgrading
    // but through unsafe code in some implementations
    
    // parking_lot::RwLock provides safe downgrade:
    // let read_guard = write_guard.downgrade();
    
    // Standard library: release and reacquire
    drop(write_guard);
    let read_guard = lock.read().unwrap();
}

std::sync::RwLock doesn't provide safe lock downgrading.

Try-Lock Variants

use std::sync::{Arc, Mutex, RwLock};
use std::thread;
 
fn main() {
    // Non-blocking lock attempts
    
    let mutex = Arc::new(Mutex::new(42));
    let rwlock = Arc::new(RwLock::new(42));
    
    // Mutex try_lock
    match mutex.try_lock() {
        Ok(guard) => println!("Mutex acquired: {}", *guard),
        Err(_) => println!("Mutex already locked"),
    }
    
    // RwLock try_read and try_write
    match rwlock.try_read() {
        Ok(guard) => println!("Read lock acquired: {}", *guard),
        Err(_) => println!("Read lock not available"),
    }
    
    match rwlock.try_write() {
        Ok(mut guard) => {
            *guard += 1;
            println!("Write lock acquired: {}", *guard);
        }
        Err(_) => println!("Write lock not available"),
    }
}

try_lock, try_read, and try_write attempt acquisition without blocking.

Deadlock Scenarios

use std::sync::{Arc, Mutex, RwLock};
use std::thread;
 
fn main() {
    // Mutex deadlock: classic ABBA pattern
    let mutex_a = Arc::new(Mutex::new(0));
    let mutex_b = Arc::new(Mutex::new(0));
    
    // Thread 1: lock A then B
    // Thread 2: lock B then A
    // Result: deadlock
    
    // RwLock has additional deadlock scenarios:
    // - Holding read lock and trying to upgrade to write
    // - Multiple threads waiting for write while readers hold lock
    
    let rwlock = Arc::new(RwLock::new(42));
    
    // This deadlocks:
    // let read_guard = rwlock.read().unwrap();
    // let write_guard = rwlock.write().unwrap();  // Blocks forever
    
    // Rule: never try to acquire write while holding read
}

RwLock has additional deadlock scenarios from read/write interaction.

Memory Overhead Comparison

use std::sync::{Mutex, RwLock};
use std::mem::size_of;
 
fn main() {
    // Mutex overhead
    struct MutexWrapper<T> {
        inner: Mutex<T>,
    }
    
    // RwLock overhead
    struct RwLockWrapper<T> {
        inner: RwLock<T>,
    }
    
    // Memory size comparison
    println!("Mutex<bool>: {} bytes", size_of::<Mutex<bool>>());
    println!("RwLock<bool>: {} bytes", size_of::<RwLock<bool>>());
    
    // RwLock is typically larger:
    // - Needs to track reader count
    // - Needs writer waiting state
    // - More complex internal state
    
    // For many instances, this can matter:
    // struct Data {
    //     values: Vec<Mutex<i32>>,  // Smaller
    // }
    // vs
    // struct Data {
    //     values: Vec<RwLock<i32>>,  // Larger
    // }
}

RwLock has larger memory footprint than Mutex.

Granular Locking Strategy

use std::sync::{Arc, Mutex, RwLock};
use std::collections::HashMap;
 
fn main() {
    // Coarse-grained: single lock for entire structure
    let coarse = Arc::new(RwLock::new(HashMap::<String, i32>::new()));
    
    // Fine-grained: lock per element or segment
    struct FineGrained {
        data: HashMap<String, i32>,
        locks: HashMap<String, Mutex<()>>,  // Lock per key
    }
    
    // Fine-grained reduces contention
    // but increases complexity
    
    // Alternative: sharded locks
    struct Sharded<K, V> {
        shards: Vec<RwLock<HashMap<K, V>>>,
    }
    
    // Use hash to determine shard
    fn get_shard<K: std::hash::Hash>(key: &K, num_shards: usize) -> usize {
        use std::collections::hash_map::DefaultHasher;
        use std::hash::{Hash, Hasher};
        let mut hasher = DefaultHasher::new();
        key.hash(&mut hasher);
        hasher.finish() as usize % num_shards
    }
}

Fine-grained locking reduces contention at the cost of complexity.

When to Prefer Mutex

use std::sync::{Arc, Mutex};
 
// Use Mutex when:
// 1. Write-heavy workloads (> 30% writes)
// 2. Lock hold time is very short
// 3. Simplicity is preferred
// 4. Fair access between readers and writers matters
// 5. Memory overhead is a concern
 
struct Counter {
    count: i64,
}
 
impl Counter {
    fn increment(&mut self) {
        self.count += 1;  // Very short hold time
    }
    
    fn get(&self) -> i64 {
        self.count
    }
}
 
fn main() {
    let counter = Arc::new(Mutex::new(Counter { count: 0 }));
    
    // Short hold times, frequent writes
    // Mutex is appropriate here
}

Mutex is better for write-heavy workloads or when simplicity matters.

When to Prefer RwLock

use std::sync::{Arc, RwLock};
use std::collections::HashMap;
 
// Use RwLock when:
// 1. Read-heavy workloads (> 70% reads)
// 2. Read operations take significant time
// 3. Many concurrent readers benefit from parallelism
// 4. Writes are infrequent
 
struct Cache {
    data: HashMap<String, String>,
}
 
impl Cache {
    fn get(&self, key: &str) -> Option<&String> {
        self.data.get(key)  // Frequent, may be slow
    }
    
    fn insert(&mut self, key: String, value: String) {
        self.data.insert(key, value);  // Infrequent
    }
}
 
fn main() {
    let cache = Arc::new(RwLock::new(Cache {
        data: HashMap::new(),
    }));
    
    // Many concurrent reads benefit from RwLock
    // Infrequent writes don't justify serialization
}

RwLock is better for read-heavy workloads with meaningful read times.

Performance Heuristics Summary

// Performance characteristics:
 
// Uncontended (single thread):
//   Mutex: ~20-30ns per lock/unlock
//   RwLock read: ~25-35ns per lock/unlock
//   RwLock write: ~25-35ns per lock/unlock
//   Difference: minimal
 
// Contended (multiple threads):
//   Mutex: serialization overhead, but simpler wake-up
//   RwLock read: parallel reads possible, lower total wait
//   RwLock write: serialization + wait for readers to finish
 
// Memory:
//   Mutex: smaller footprint
//   RwLock: larger (reader count, state)
 
// Decision heuristic:
//   < 70% reads: prefer Mutex
//   > 90% reads: prefer RwLock
//   70-90% reads: benchmark both

The break-even point depends on specific workload characteristics.

Summary Table

| Aspect | Arc<Mutex<T>> | Arc<RwLock<T>> | |--------|-----------------|------------------| | Concurrent readers | No | Yes | | Concurrent writer + reader | No | No | | Per-operation overhead | Lower | Higher | | Memory footprint | Smaller | Larger | | Write-heavy performance | Better | Worse | | Read-heavy performance | Worse | Better | | Writer fairness | Equal access | May starve | | Lock types | One (lock) | Two (read, write) | | Downgrade support | N/A | Limited | | Deadlock scenarios | Standard | Read/write interaction | | Complexity | Simple | Moderate |

Synthesis

The choice between Arc<Mutex<T>> and Arc<RwLock<T>> is about trading simplicity and overhead for read concurrency:

Mutex: Single lock type, lower overhead, fair access for all operations. Every lock acquisition is identical: wait for exclusive access, use the data, release. For write-heavy workloads or when lock hold times are short, Mutex wins because the coordination overhead of RwLock isn't justified. The simpler state machine inside Mutex means faster uncontended operations and smaller memory footprint.

RwLock: Two lock types (read/write), higher overhead, enables concurrent reads. When reads dominate and hold times are meaningful, multiple readers can proceed in parallel, providing throughput that Mutex cannot match. However, RwLock can starve writers—a continuous stream of readers may indefinitely delay a waiting writer. The coordination overhead (tracking reader count, managing writer queues) adds cost to every operation.

Key insight: The overhead difference matters most for high-frequency, short-duration locks. If you're locking millions of times per second for nanosecond operations, Mutex overhead adds up. If reads hold the lock for microseconds or longer, RwLock parallelism wins despite higher per-operation cost. Measure your specific workload: count read vs write frequency, measure lock hold duration, and benchmark both approaches. For contested write-heavy data, Mutex is often the right choice despite being "less capable"—the complexity of RwLock coordination becomes pure overhead when writes dominate. For read-heavy caches or configuration where reads vastly outnumber writes, RwLock concurrency wins.

Loading page…

What are the trade-offs between Arc<Mutex<T>> and Arc<RwLock<T>> for shared mutable state?

Basic Mutex Usage

Basic RwLock Usage

Concurrent Reader Demonstration

Mutex Blocks All Operations

Read-Heavy Workload Performance

Write-Heavy Workload Performance

RwLock Internal Structure

Mutex Internal Structure

Writer Starvation in RwLock

Fair RwLock Behavior

Poisoning Behavior

Poisoning Recovery

Read Guard vs Write Guard

Downgrading Write Lock

Try-Lock Variants

Deadlock Scenarios

Memory Overhead Comparison

Granular Locking Strategy

When to Prefer Mutex

When to Prefer RwLock

Performance Heuristics Summary

Summary Table

Synthesis

What are the trade-offs between Arc<Mutex<T>> and Arc<RwLock<T>> for shared mutable state?

Basic Mutex Usage

Basic RwLock Usage

Concurrent Reader Demonstration

Mutex Blocks All Operations

Read-Heavy Workload Performance

Write-Heavy Workload Performance

RwLock Internal Structure

Mutex Internal Structure

Writer Starvation in RwLock

Fair RwLock Behavior

Poisoning Behavior

Poisoning Recovery

Read Guard vs Write Guard

Downgrading Write Lock

Try-Lock Variants

Deadlock Scenarios

Memory Overhead Comparison

Granular Locking Strategy

When to Prefer Mutex

When to Prefer RwLock

Performance Heuristics Summary

Summary Table

Synthesis

What are the trade-offs between `Arc<Mutex<T>>` and `Arc<RwLock<T>>` for shared mutable state?

What are the trade-offs between `Arc<Mutex<T>>` and `Arc<RwLock<T>>` for shared mutable state?