Mastering Rust Concurrency: Arc, Mutex, and Channel - The Three Guardians of Thread Safety

Follow Dream Beast Programming WeChat Official Account for humorous Rust learning.

Personal website: rexai.top

Have you ever found yourself pounding your chest in the middle of the night, frustrated by a multithreading bug?

Imagine a chaotic kitchen where several chefs (threads) are cooking simultaneously. They’re fighting over the same knife, modifying the same menu at the same time, and even worse - someone just threw the recipe in the trash while another person runs over trying to follow it. The result? Either fingers get cut or the recipe gets completely messed up, ultimately serving up a “Schrödinger’s dish” - the taste depends entirely on luck.

This is concurrent programming in many languages - powerful, but full of chaos and danger. You have to be like a worried mother, setting up roadblocks everywhere (like various locks), constantly reminding yourself not to make mistakes, but if you’re not careful, disaster strikes.

Now, let’s step into Rust’s kitchen.

This kitchen is a bit different. At the entrance stands an extremely strict, even somewhat nagging butler (the Rust compiler). He won’t let you just start cooking randomly, but will point out all potential problems in advance, shouting at you: “Hey! You can’t give that knife to someone else unless you’re sure you’re done with it!” “Hey! That menu is shared, only one person can modify it at a time!”

Though a bit annoying, the result is: absolute safety. You can put a hundred chefs in this kitchen, and they can work together in perfect order without any accidents.

This is the charm of Rust’s concurrent programming: it transfers the “worrying” work from your brain to the compiler. You just need to understand and follow the butler’s few core rules to write safe, efficient “foolproof” concurrent code.

Today, we’ll break down this “butler’s” rules in plain language.

Rule One: Want to Create Clones? Learn to “Let Go” First

In Rust, starting a new thread is like creating a clone of yourself to do work. We use the thread::spawn spell.

But this butler (compiler) has a strict rule: you can’t casually lend your tools (data) to your clone, because if you finish using them and destroy the tools, when the clone tries to use them, the program crashes (dangling pointer).

The butler requires you to explicitly “gift” them. Use the move keyword to tell him: “I don’t want this thing anymore, I’m giving full authority to my clone!”

Look at the code:

use std::thread;

fn main() {
    let name = String::from("Dream Beast Programming");
    let handle = thread::spawn(move || {
        println!("My clone says: Hello, {name}");
    });
    // If you uncomment the line below, the butler will immediately slap your hand
    // println!("I say: Hello, {name}");
    handle.join().unwrap(); // Wait for the clone to finish work
}

See? Once you move the name variable to the clone thread, the original loses ownership of it. It’s like giving your only house key to your roommate - you can no longer enter the door. This seemingly tyrannical rule fundamentally prevents the chaos of “two people trying to open the door with the same key simultaneously.”

Sometimes, we don’t want to completely give things away, but want many clones to be able to “read-only” share some materials, like a shared “cooking guide” for all staff.

Direct sharing? The butler will jump out to stop you again. Because he doesn’t know who will finish reading first, who will finish last, what if the owner of the materials (main thread) leaves early and burns the guide?

At this point, we need a magical tool: Arc<T>, short for “Atomic Reference Counting.”

Don’t be scared by the name, think of it as a “shared reading room in a library.”

Arc::new(data) puts a piece of material into this reading room. Whenever a clone wants to read this material, they get a reading card, which is Arc::clone(&data). This process is very lightweight, just increasing the count of “current readers.”

When the clone finishes reading and leaves, their reading card automatically becomes invalid (count decreases by one). Until the last reader also leaves, the reading room closes and the material is destroyed.

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

fn main() {
    let cooking_guide = Arc::new(vec!["Step 1: Wash vegetables", "Step 2: Cut vegetables", "Step 3: Cook"]);

    for i in 0..3 {
        let guide_for_clone = Arc::clone(&cooking_guide);
        thread::spawn(move || {
            println!("Chef {i} is reading the guide: {:?}", guide_for_clone);
        });
    }
    // Wait a bit for the chefs to have time to read
    thread::sleep(std::time::Duration::from_secs(1));
}

Through Arc, we safely achieve “shared read-only” data. Like library rules, you can look, you can copy, but you absolutely cannot scribble on the original.

Rule Three: Want to Modify Shared Data? Enter the “Single VIP Room”

Alright, here comes the real challenge. What if multiple clones need to modify the same shared data? Like a bank account balance.

If everyone goes at it together, you add 100, I subtract 50, the CPU goes wild, and in the end, what the balance becomes depends entirely on fate. This is the evil “data race.”

Rust’s butler absolutely detests this. He has prepared another powerful weapon for you: Mutex<T>, short for “Mutual Exclusion.”

Think of it as a “single VIP room” containing the shared data we need to modify. This room has only one key.

When a clone wants to modify the data, they must first get the key, which is calling the .lock() method. Once they get the key and enter the room, the door locks, and anyone else who wants to come in has to wait in line outside.

When they finish modifying and leave the room (exit the scope), the key is automatically returned. At this point, the next person in line can get the key and go in.

This way, no matter how many people want to modify, at any given time, only one person can succeed. The “atomicity” of data modification is absolutely guaranteed.

However, Mutex itself cannot be directly passed between threads. It needs to team up with our old friend Arc.

Ultimate Combination: Arc + Mutex = Thread-Safe Shared Modification

Arc<Mutex<T>> is the most common and powerful combination in Rust concurrent programming.

Arc is responsible for making the “key” to this “single VIP room” safely visible and obtainable by all clones. Mutex is responsible for ensuring that even though all clones can get the key, only one person can enter the room at a time.

Let’s look at a classic counter example: 10 clones, each wanting to increment the counter by 1.

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

fn main() {
    // Put a counter with initial value 0 into a single room (Mutex), then put the key distributor for this room into the library (Arc)
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            // Want to modify data? Get the key and enter the room first!
            let mut num = counter_clone.lock().unwrap();
            *num += 1;
            // Leave the room, key automatically returned
        });
        handles.push(handle);
    }

    // Wait for all clones to finish work
    for handle in handles {
        handle.join().unwrap();
    }

    // Finally, we get the key ourselves and go in to see the result
    println!("Final result: {}", *counter.lock().unwrap());
}

The final result will be exactly 10! This is the power of Arc<Mutex<T>>. It uses a seemingly cumbersome method to achieve 100% peace of mind.

Rule Four: Don’t Want Shared State? Try the “Dedicated Messenger”

Sometimes, sharing memory and locks between threads is still too troublesome, like chefs crowding around one workstation. A better approach is for each chef to have their own independent workstation, with semi-finished products sent to the next chef through a dedicated conveyor belt (Channel).

This is the “Channel” mechanism, a way to communicate through message passing rather than shared memory.

In Rust, we use mpsc::channel to create a channel. mpsc means “Multiple Producer, Single Consumer.” Like a post office, many people (producers) can send letters to one mailbox (consumer).

use std::sync::mpsc;
use std::thread;

fn main() {
    // Create a channel, tx is the sender (transmitter), rx is the receiver
    let (tx, rx) = mpsc::channel();

    thread::spawn(move || {
        // The clone creates a package and sends it through the sender tx
        tx.send("A package from the future").unwrap();
    });

    // The main thread waits at the receiver rx, recv() will wait until the package arrives
    let received = rx.recv().unwrap();
    println!("Received package: {}", received);
}

This approach makes collaboration between threads very decoupled and clear. You do your thing, I do mine, and when we need to communicate, we just send a message. This aligns with Rust’s philosophy: “Don’t communicate through shared memory, share memory through communication.”

Summary: Embrace the “Nagging” for Peace of Mind

Let’s review the four major rules of Rust’s kitchen:

move: If you want your clone to work, you must completely transfer ownership of the tools.
Arc<T>: If you want everyone to read materials together, put them in the “shared reading room.”
Arc<Mutex<T>>: If you want everyone to modify things together, lock them in the “single VIP room” and share the key distributor.
channel: If you don’t want to crowd together, give them dedicated “message conveyor belts.”

Rust’s concurrency model is fundamentally about its ownership system. The compiler, this strict butler, helps you avoid all possible runtime chaos by enforcing these seemingly rigid rules at compile time.

At first, you might find him annoying and restrictive. But when you truly experience that peace of mind - never worrying about data races, never fearing concurrent bugs - you’ll understand this butler’s good intentions. You’ll sincerely exclaim:

“Delicious!”

Follow Dream Beast Programming WeChat Official Account to unlock more cutting-edge tech.

Mastering Rust Concurrency: Arc, Mutex, and Channel - The Three Guardians of Thread Safety#

Rule One: Want to Create Clones? Learn to “Let Go” First#

Rule Two: Want to Share “Read-Only” Materials? Use the “Atomic” Library#

Rule Three: Want to Modify Shared Data? Enter the “Single VIP Room”#

Ultimate Combination: Arc + Mutex = Thread-Safe Shared Modification#

Rule Four: Don’t Want Shared State? Try the “Dedicated Messenger”#

Summary: Embrace the “Nagging” for Peace of Mind#