--- title: "Deadlocks en C vs Rust : Que garantit vraiment Rust ?" description: "Les deadlocks ne sont pas évités par le compilateur, mais Rust offre des garanties de sécurité qui rendent leur apparition plus difficile qu'en C. Comparaison détaillée." url: "https://mayorana.ch/fr/blog/deadlocks-c-vs-rust" language: "fr" date: "2025-08-25" author: "Mohamed Bennekrouf" tags: - "rust" - "c" - "concurrence" - "deadlock" en_version: "https://mayorana.ch/en/blog/deadlocks-c-vs-rust.md" --- # Deadlocks en C vs Rust : Que garantit vraiment Rust ? Les deadlocks sont des bugs **concurrentiels à l'exécution**, pas des erreurs détectées à la compilation. Alors pourquoi dit-on que Rust est plus sûr pour la programmation multithread ? Voyons ce que Rust empêche vraiment — et ce qu'il ne peut pas empêcher. ## Qu'est-ce qu'un deadlock ? Un deadlock apparaît lorsque plusieurs threads détiennent des ressources et attendent indéfiniment que les autres les libèrent. Il faut que ces **4 conditions de Coffman** soient réunies : 1. **Exclusion mutuelle** — au moins une ressource ne peut pas être partagée 2. **Maintien et attente** — un thread détient une ressource et en attend une autre 3. **Pas de préemption** — les ressources ne peuvent pas être reprises de force 4. **Attente circulaire** — les threads s'attendent mutuellement en boucle Rust **n’élimine pas** les deadlocks, mais fournit des outils pour mieux les éviter. ## Exemple de deadlock en C et en Rust ### En C (Pthreads) : ```c pthread_mutex_lock(&a); // traitement pthread_mutex_lock(&b); // risque de deadlock si un autre thread a bloqué `b` puis `a` ``` ### En Rust ```rust let a = Arc::new(Mutex::new(())); let b = Arc::new(Mutex::new(())); let t1 = { let a = Arc::clone(&a); let b = Arc::clone(&b); std::thread::spawn(move || { let _a = a.lock().unwrap(); let _b = b.lock().unwrap(); // même problème si ordre de verrouillage inversé }) }; ``` 💥 Dans les deux cas, un deadlock est possible si les threads verrouillent les ressources dans des ordres différents.
Thread 1 détient Mutex A Mutex B verrouillé, attendu Thread 2 détient Mutex B Mutex A verrouillé, attendu attend bloqué par attend bloqué par Attente circulaire — aucun contrôle du compilateur ne la détecte
## Les garanties supplémentaires de Rust | Fonctionnalité | C (Pthreads) | Rust | Pourquoi c’est important | |-----------------------------|---------------|---------------------------|----------------------------------------| | Suivi de possession | ❌ | ✅ (Vérifié par le compilateur) | Évite l'usage concurrent non sûr | | Déverrouillage automatique | ❌ | ✅ (via `Drop` / RAII) | Empêche d'oublier de libérer un lock | | Partage sécurisé de verrous | ❌ | ✅ (`Arc>`) | Semantique claire entre threads | | Prévention des data races | ❌ | ✅ (en code sûr uniquement) | Évite des scénarios de deadlocks | | Prévention des deadlocks | ❌ | ❌ | Nécessite une logique explicite | ## Le cycle de vie des verrous en Rust Rust garantit que : - Les verrous sont libérés automatiquement en fin de scope - Un mutex ne peut pas être accédé sans être verrouillé - Les règles d’emprunt empêchent les accès concurrents non valides La différence avec C se joue du côté du *déverrouillage*. En C, l'unlock est une instruction qu'il faut atteindre ; en Rust, c'est une implémentation de `Drop` qui s'exécute sur chaque chemin de sortie du scope :
C — l'unlock est une instruction Rust — l'unlock est un destructeur pthread_mutex_lock(&m) le verrou est détenu par ce thread if (err) return; la sortie précoce saute la suite pthread_mutex_unlock(&m) jamais atteint sur le chemin d'erreur Le mutex reste verrouillé le thread suivant se bloque indéfiniment let g = m.lock().unwrap(); le MutexGuard possède le verrou if err { return; } sortie précoce — ou panique — hors du scope drop(g) — inséré par le compilateur exécuté sur tous les chemins, unwind inclus Libéré, toujours un mode de défaillance en moins à gérer RAII supprime l'oubli de déverrouillage — pas le bug d'ordre de verrouillage
Mais : **Rust ne vérifie pas l’ordre de verrouillage**. Si un thread verrouille `a` puis `b`, et un autre `b` puis `a`, un deadlock peut quand même se produire. ## Compilation vs Exécution | Problème | Détecté en C ? | Détecté en Rust ? | Sécurité à la compilation ? | |-----------------------------|----------------|--------------------|------------------------------| | Data races | ❌ | ✅ | ✅ | | Use-after-free | ❌ | ✅ | ✅ | | Pointeurs pendants | ❌ | ✅ | ✅ | | Ordre de verrouillage cyclique | ❌ | ❌ | ❌ | | Deadlocks | ❌ | ❌ | ❌ | ## Outils dynamiques pour détecter les deadlocks Rust ne vérifie pas l'ordre des locks à la compilation, mais tu peux utiliser : - [`loom`](https://docs.rs/loom) – test d'interleavings concurrents - [`deadlock`](https://docs.rs/deadlock) – détection de deadlocks en mode debug - Analyseurs statiques (en développement) ## Résumé ✅ **Rust** garantit la sûreté mémoire et empêche les erreurs classiques de synchronisation ❌ **Les deadlocks** sont toujours possibles — à toi de gérer l’ordre des verrous Structure tes locks proprement, et teste avec des outils comme `loom` Deux threads qui verrouillent la même paire de `Mutex` dans l'ordre inverse finiront par se bloquer, et Rust compilera ça sans broncher. C'est la limite de ce que le système de types t'achète : il exclut les [data races](https://mayorana.ch/fr/blog/ownership-safety-rust-fr), pas les deadlocks.