Concurrency in Rust: Sharing State Safely with Arc, Mutex, and RwLock

Why Shared State Still Matters

Rust promotes message passing, but many workloads still need shared state:

1. in-memory counters.
2. caches.
3. connection pools.
4. metrics registries.

The challenge is correctness under parallel access. Rust addresses this with ownership + synchronization primitives.

The Foundation: Mutex<T>

Mutex<T> guarantees only one thread mutates protected data at a time.

use std::sync::Mutex;

fn main() {
    let value = Mutex::new(0);
    {
        let mut guard = value.lock().unwrap();
        *guard += 1;
    } // lock released automatically here
}

The lock is released by RAII when guard is dropped.

Why Mutex<T> Alone Is Not Enough

A single Mutex<T> has one owner. Threads need shared ownership too.

That is why the idiomatic combination is:

1. Arc<T> for multi-owner sharing across threads.
2. Mutex<T> for exclusive mutation.

Together: Arc<Mutex<T>>.

Canonical Pattern: Arc<Mutex<T>>

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

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = Vec::new();

    for _ in 0..10 {
        let c = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            let mut n = c.lock().unwrap();
            *n += 1;
        }));
    }

    for h in handles {
        h.join().unwrap();
    }

    println!("result={}", *counter.lock().unwrap());
}

RwLock<T> for Read-Heavy Workloads

RwLock<T> allows:

1. many concurrent readers, or
2. one writer.

Use when reads dominate writes.

use std::sync::RwLock;

let config = RwLock::new(String::from("v1"));
let read_guard = config.read().unwrap();
drop(read_guard);
let mut write_guard = config.write().unwrap();
write_guard.push_str("-updated");

Lock Poisoning and Recovery

If a thread panics while holding a lock, Rust marks it poisoned.

let guard = mutex.lock().unwrap_or_else(|poisoned| poisoned.into_inner());

Poisoning is a safety signal. Decide explicitly whether state can still be trusted.

Deadlock Risks and Prevention

Rust prevents data races in safe code, but deadlocks are still possible.

Prevention checklist:

1. Always acquire locks in a global fixed order.
2. Keep critical sections small.
3. Do not call blocking/network operations while holding locks.
4. Prefer lock-free message passing for complex coordination.

Channels vs Shared State

Choose based on ownership model:

1. Channels (mpsc, async channels): best when ownership transfer fits naturally.
2. Shared locks: best when many workers need direct access to shared in-memory structure.

Often hybrid architecture works best.

Async Context Considerations

In async Rust:

1. std::sync::Mutex can block executor threads.
2. Prefer tokio::sync::Mutex for async tasks.

But do not over-lock async code. Consider sharding state or actor model.

Performance Tuning Tips

1. Minimize lock contention by sharding maps/counters.
2. Use atomics (AtomicU64, etc.) for simple numeric stats.
3. Benchmark Mutex vs RwLock under realistic traffic.
4. Profile tail latency, not only throughput.

Practical Pattern: Metrics Counter

For high-frequency counters, this is often better than global mutex:

1. per-thread local counters.
2. periodic aggregation.

This reduces hot lock contention on the fast path.

Conclusion

Rust shared-state concurrency is powerful when modeled explicitly:

1. Arc<Mutex<T>> for general mutable shared data.
2. RwLock<T> for read-heavy cases.
3. atomics/channels for specialized performance patterns.

Use Rust’s type system as a design partner and keep synchronization boundaries simple.

Resources

• Rust Book: Fearless Concurrency
• std::sync::Mutex
• std::sync::RwLock
• Tokio Synchronization