Shared state overview in Rust - Step-by-Step Execution

Concept Flow - Shared state overview

Start: Create shared state

↓

Multiple threads access shared state

↓

Use synchronization (Mutex, Arc)

↓

Threads read/write safely

↓

Threads finish work

↓

Shared state dropped

This flow shows how shared state is created, accessed safely by multiple threads using synchronization, and then cleaned up.

Execution Sample

Rust

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

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

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

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

This code creates a shared counter protected by a mutex and shared safely across threads.

Execution Table

Step	Action	Thread	Mutex Lock	Counter Value	Output/Note
1	Create Arc<Mutex> with 0	Main	Unlocked	0	Shared state initialized
2	Spawn thread 1	Thread 1	Lock acquired	0	Thread 1 locks mutex
3	Increment counter	Thread 1	Locked	1	Counter incremented to 1
4	Unlock mutex	Thread 1	Unlocked	1	Thread 1 releases lock
5	Spawn thread 2	Thread 2	Lock acquired	1	Thread 2 locks mutex
6	Increment counter	Thread 2	Locked	2	Counter incremented to 2
7	Unlock mutex	Thread 2	Unlocked	2	Thread 2 releases lock
8	Spawn thread 3	Thread 3	Lock acquired	2	Thread 3 locks mutex
9	Increment counter	Thread 3	Locked	3	Counter incremented to 3
10	Unlock mutex	Thread 3	Unlocked	3	Thread 3 releases lock
11	All threads joined	Main	Unlocked	3	Final counter value is 3

💡 All threads finished, shared counter safely incremented to 3

Variable Tracker

Variable	Start	After Thread 1	After Thread 2	After Thread 3	Final
counter (Mutex guard)	0	1	2	3	3
Arc strong count	1	2	2	2	1

Key Moments - 3 Insights

Why do we need Arc when sharing state between threads?

Arc allows multiple ownership of the shared state safely across threads, as shown in steps 2, 5, and 8 where threads clone the Arc.

What happens if we try to access the counter without locking the mutex?

Without locking, simultaneous access can cause data races. The mutex lock in steps 2, 5, and 8 ensures only one thread accesses the counter at a time.

Why does the counter value increase step by step instead of all at once?

Each thread locks the mutex, increments the counter, then unlocks it before the next thread accesses it, ensuring safe sequential updates (see steps 3, 6, 9).

Visual Quiz - 3 Questions

Look at the execution table, what is the counter value after Thread 2 releases the mutex?

A 1

B 3

C 2

D 0

💡 Hint

Check step 7 in the execution table where Thread 2 unlocks the mutex.

At which step does the mutex lock get acquired for the third time?

A Step 6

B Step 8

C Step 3

D Step 10

💡 Hint

Look for the 'Lock acquired' action in the execution table.

If we remove Arc and share Mutex directly, what would happen?

A Compile error due to ownership rules

B Runtime panic due to data race

C Code compiles and runs fine

D Counter never increments

💡 Hint

Arc is needed for multiple ownership across threads, see key moment about Arc.

Concept Snapshot

Shared state in Rust uses Arc for multiple ownership and Mutex for safe access.
Arc clones increase reference count for threads.
Mutex locks prevent data races by allowing one thread at a time.
Threads clone Arc, lock Mutex, modify data, then unlock.
Final shared state is dropped when all owners go out of scope.

Full Transcript

This example shows how Rust manages shared state safely across threads. We start by creating a shared counter wrapped in a Mutex and inside an Arc. The Arc allows multiple threads to own the counter. Each thread clones the Arc to get access. Before changing the counter, a thread locks the mutex to ensure exclusive access. It increments the counter, then unlocks the mutex. This process repeats for each thread. The execution table traces each step: locking, incrementing, unlocking. The variable tracker shows how the counter value changes from 0 to 3. Key moments explain why Arc and Mutex are needed to avoid data races and ownership errors. The visual quiz tests understanding of the counter value at different steps, mutex locking order, and the role of Arc. This approach ensures safe, synchronized shared state in Rust multithreading.