Send, Sync & Arc<Mutex<T>> Send, Sync & Arc<Mutex<T>>

Deux traits qu'on n'écrit jamais décident ce qui a le droit de traverser un thread.Two traits you never write decide what is allowed to cross a thread.

Le numéro précédent a laissé une porte fermée. move donne une donnée à un seul thread ; thread::scope la prête à plusieurs, mais en lecture seule — parce que « aliasing XOR mutation » interdit que deux threads la tiennent pendant que l'un écrit. Reste le cas le plus courant en pratique : plusieurs threads qui veulent muter la même donnée. Un compteur, un cache, un état partagé. Avant d'y arriver, il faut nommer la mécanique invisible qui gouvernait déjà le refus du №1 : Send et Sync. Ce sont deux traits marqueurs, auto-dérivés par le compilateur, qui répondent à deux questions précises — cette donnée peut-elle partir dans un autre thread (Send) ? une référence vers elle peut-elle être partagée entre threads (Sync) ? Toute la sûreté de la concurrence en Rust repose sur ces deux réponses, calculées à la compilation, sans qu'on écrive une ligne.The previous issue left one door shut. move gives data to a single thread; thread::scope lends it to several, but read-only — because 'aliasing XOR mutation' forbids two threads holding it while one writes. That leaves the most common case in practice: several threads wanting to mutate the same data. A counter, a cache, a shared state. Before getting there, we must name the invisible machinery that already governed the №1 refusal: Send and Sync. These are two marker traits, auto-derived by the compiler, answering two precise questions — can this data leave for another thread (Send)? can a reference to it be shared between threads (Sync)? All of Rust's concurrency safety rests on these two answers, computed at compile time, without writing a line.

// la signature de thread::spawn impose DEUX bornes — pas une
pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T + Send + 'static,    // 'static (vu au №1) ET Send (ce numéro)
    T: Send + 'static;

// 'static  → « ne dépend d'aucun emprunt à durée limitée »   (le QUAND)
// Send     → « la possession peut PARTIR vers un autre thread » (le QUOI)
// le refus du №1 portait sur la durée de vie. voici l'autre moitié : ce qui a
// le DROIT de traverser. un Rc, par exemple, ne l'a pas — et le compilateur le sait.

On change Rc en Arc… et la donnée reste obstinément en lecture seule.You swap Rc for Arc… and the data stays stubbornly read-only.

Le réflexe pour partager une donnée entre threads vient du Vol 6 : un compteur de références. On tente Rc — et le compilateur refuse avec un message inhabituel, qui parle de Send et de threads, pas de durée de vie. La raison est exactement la distinction du Vol 6 №2 : Rc compte ses références sans atomicité, donc deux threads le manipulant en parallèle corromptraient le compte. Arc, lui, utilise un compteur atomique : il est Send, il traverse. Premier obstacle levé. Mais on découvre alors le second, plus subtil : Arc partage la possession, et plusieurs Arc sont autant d'accès partagés — autant de &. Or le Vol 1 l'a gravé : on n'écrit pas à travers un &. Arc a réglé l'envoi sans rien régler de la mutation. La donnée a traversé ; elle reste figée.The reflex for sharing data across threads comes from Vol 6: a reference count. You try Rc — and the compiler refuses with an unusual message, about Send and threads, not lifetimes. The reason is exactly Vol 6 №2's distinction: Rc counts its references without atomicity, so two threads handling it in parallel would corrupt the count. Arc uses an atomic counter: it's Send, it crosses. First obstacle cleared. But then you meet the second, subtler one: Arc shares ownership, and several Arcs are that many shared accesses — that many &. Yet Vol 1 carved it: you don't write through a &. Arc fixed the sending without fixing anything about mutation. The data crossed; it stays frozen.

use std::rc::Rc;
use std::thread;

let compteur = Rc::new(0);
let c = Rc::clone(&compteur);
thread::spawn(move || {
    println!("{}", c);          // ✕ error[E0277]: `Rc<i32>` cannot be sent between
});                             //   threads safely — the trait `Send` is not implemented
// Rc compte ses références SANS atomicité. deux threads clonant/lâchant en même temps
// corromptraient le compteur → double libération ou fuite. le compilateur refuse net.

L'erreur ne dit pas « ça plantera » — elle dit Rc<i32> cannot be sent between threads safely. C'est Send qui parle. Le Vol 6 avait présenté Rc vs Arc comme un choix de performance (atomique = un peu plus cher) ; on voit ici que c'en est aussi un de sûreté vérifiée à la compilation. Rc n'est pas Send, donc il ne peut littéralement pas entrer dans une closure de thread. La course sur le compteur est rendue inexprimable, pas seulement déconseillée.The error doesn't say 'it will crash' — it says Rc<i32> cannot be sent between threads safely. That's Send speaking. Vol 6 presented Rc vs Arc as a performance choice (atomic = slightly costlier); here we see it's also a compile-time-checked safety one. Rc isn't Send, so it literally cannot enter a thread's closure. The race on the counter is made inexpressible, not merely discouraged.

Le Mutex est le borrow check du Vol 1 — qui bloque au lieu de prouver.The Mutex is Vol 1's borrow check — that blocks instead of proving.

Arc<Mutex<T>> se lit comme une phrase : Arc partage la possession entre threads (compteur atomique, Vol 6), Mutex rétablit l'exclusivité de l'accès. Le Mutex tient un verrou ; pour toucher la donnée, un thread appelle lock(), qui bloque jusqu'à ce que le verrou soit libre, puis le prend et rend un MutexGuard — l'unique &mut vers l'intérieur. Tant qu'un thread tient ce guard, les autres lock() attendent. Quand le guard est lâché (sa destruction), le verrou se libère et le thread suivant passe. C'est, trait pour trait, la règle « un seul écrivain » du Vol 1 — mais arbitrée à l'exécution par un verrou, et appliquée en faisant patienter, non en refusant de compiler. Et c'est Sync qui légitime le tout : Mutex<T> est Sync, donc &Mutex peut être partagé entre threads sans danger.Arc<Mutex<T>> reads like a sentence: Arc shares ownership across threads (atomic counter, Vol 6), Mutex restores exclusivity of access. The Mutex holds a lock; to touch the data, a thread calls lock(), which blocks until the lock is free, then takes it and returns a MutexGuard — the sole &mut to the inside. As long as one thread holds that guard, the other lock() calls wait. When the guard is dropped (its destruction), the lock releases and the next thread goes. It is, trait for trait, Vol 1's 'single writer' rule — but arbitrated at runtime by a lock, and enforced by making threads wait, not by refusing to compile. And Sync legitimizes the whole thing: Mutex<T> is Sync, so &Mutex can be shared across threads without danger.

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

let compteur = Arc::new(Mutex::new(0));       // Arc : partage la possession · Mutex : l'exclusivité
let mut handles = vec![];

for _ in 0..10 {
    let c = Arc::clone(&compteur);            // chaque thread reçoit un clone de l'Arc
    handles.push(thread::spawn(move || {
        let mut n = c.lock().unwrap();        // lock() BLOQUE jusqu'à obtenir l'accès exclusif
        *n += 1;                              // ← un seul thread est ici à la fois
    }));                                      // le guard `n` est lâché ici → le verrou se libère
}
for h in handles { h.join().unwrap(); }
println!("{}", *compteur.lock().unwrap());    // 10, toujours — jamais de data race

// pourquoi &Mutex<T> peut être partagé entre threads : Mutex est Sync
unsafe impl<T: Send> Sync for Mutex<T> {}     // impl MANUELLE : la std prouve elle-même le Sync

// Mutex<T> est Sync (si T: Send) → &Mutex<T> est Send → Arc<Mutex<T>> traverse et se partage.
// le verrou est ce qui REND légitime le partage d'un accès mutable : il garantit, à
// l'exécution, qu'un seul thread tient le &mut à un instant donné. la preuve statique
// du Vol 1 devient une garantie dynamique — exactement comme RefCell, mais qui BLOQUE
// au lieu de paniquer, parce qu'entre threads « attendre son tour » a un sens.

Un gros Mutex « par sécurité » qui sérialise tout — et tue le parallélisme.One big Mutex 'for safety' that serializes everything — and kills the parallelism.

Une fois Arc<Mutex<T>> en main, le réflexe est de tout y mettre : un seul Mutex autour de l'état entier, verrouillé au début de chaque tâche, relâché à la fin. C'est sûr — le compilateur est content, aucun data race. Mais on a oublié pourquoi on avait lancé des threads. Si chaque thread prend le verrou global et le tient pendant tout son travail, alors un seul avance à la fois : les autres font la queue. On a payé le coût du multi-threading (création de threads, synchronisation, complexité) pour obtenir une exécution… séquentielle. Le Mutex ne doit protéger que la section critique — l'instant précis où l'on touche la donnée partagée — et la libérer aussitôt. Mieux : pour un compteur, un atomique se passe de verrou ; pour une donnée surtout lue, un RwLock laisse les lecteurs avancer ensemble.Once Arc<Mutex<T>> is in hand, the reflex is to put everything in it: a single Mutex around the whole state, locked at each task's start, released at its end. It's safe — the compiler is happy, no data race. But you've forgotten why you spawned threads. If every thread takes the global lock and holds it for all its work, then only one advances at a time: the others queue. You paid the cost of multithreading (thread creation, synchronization, complexity) to get… sequential execution. The Mutex should protect only the critical section — the precise moment you touch the shared data — and release it at once. Better: for a counter, an atomic needs no lock; for mostly-read data, an RwLock lets readers advance together.

// Le réflexe : un seul gros Mutex autour de TOUT l'état, « par sécurité »
struct Etat { compteur: u64, cache: HashMap<u32, String>, journal: Vec<String> }
let etat = Arc::new(Mutex::new(Etat { /* … */ }));

// dans chaque thread :
let mut e = etat.lock().unwrap();      // ← prend le verrou GLOBAL
e.compteur += 1;                       // …même pour ne toucher qu'un champ
recalculer(&mut e.cache);              // et on le tient pendant TOUT le travail long
e.journal.push(ligne);
// pendant ce temps, les 7 autres threads sont BLOQUÉS sur le même verrou. on a écrit
// du parallèle qui s'exécute en SÉRIE : le Mutex a tué le parallélisme qu'on cherchait.

// Verrouiller le PLUS PETIT, le PLUS BREF — ou pas du tout
let compteur = Arc::new(AtomicU64::new(0));         // un compteur → un atomique, sans verrou
let cache = Arc::new(RwLock::new(HashMap::new()));  // lecture massive → RwLock (N lecteurs //)

// dans chaque thread :
compteur.fetch_add(1, Ordering::Relaxed);           // incrément atomique, zéro blocage
{
    let c = cache.read().unwrap();                  // plusieurs threads LISENT en parallèle
    utiliser(&c);
}                                                    // section critique réduite au minimum
// chaque donnée a son propre verrou (ou aucun) : les threads avancent vraiment ensemble.

La règle tient en une image : un Mutex est un goulot. Plus la section critique est large et longue, plus le goulot étrangle. La bonne granularité, c'est de verrouiller la plus petite donnée possible, le moins longtemps possible, et de préférer les outils sans verrou quand ils existent — AtomicU64 pour un compteur, RwLock quand les lectures dominent (il autorise N lecteurs simultanés, un seul écrivain). Le but n'est jamais « ajouter de la synchronisation » ; c'est « en mettre juste assez pour que ce soit correct, et pas un instant de plus ».The rule fits in one image: a Mutex is a bottleneck. The wider and longer the critical section, the more it chokes. The right granularity is to lock the smallest possible data, for the shortest possible time, and to prefer lock-free tools when they exist — AtomicU64 for a counter, RwLock when reads dominate (it allows N simultaneous readers, one writer). The goal is never 'add synchronization'; it's 'add just enough to be correct, and not a moment more'.