---
title: "Comment les mécanismes d'Ownership et de Borrowing Assurent une Concurrence Sûre"
description: "Ownership et borrowing excluent les data races à la compilation. Ce qu'ajoutent Send et Sync, et pourquoi Rc ne franchit pas un thread."
url: "https://mayorana.ch/fr/blog/concurrency-rust-fr"
language: "fr"
date: "2025-11-25"
author: "Mohamed Bennekrouf"
tags:
- "rust"
- "beginner"
- "memory"
- "concurrency"
- "ownership"
- "borrowing"
en_version: "https://mayorana.ch/en/blog/concurrency-rust.md"
---
# Comment les mécanismes d'Ownership et de Borrowing Assurent une Concurrence Sûre
Le modèle de concurrence de Rust exploite ses règles d'ownership et de borrowing pour garantir la thread safety au moment de la compilation, éliminant les [data races](https://mayorana.ch/fr/blog/ownership-safety-rust-fr) sans nécessiter un [garbage collector](https://mayorana.ch/fr/blog/why-garbage-collector-fr). Cette approche assure un parallélisme sûr et haute performance avec un overhead runtime minimal.
## Modèle de concurrence de Rust
Rust utilise les mécanismes suivants pour gérer la concurrence :
- **Ownership** : Assure l'accès mutable exclusif aux données.
- **Borrowing** : Gouverne comment les données sont accédées via des références.
- **Lifetimes** : Préviennent les [dangling references](https://mayorana.ch/fr/blog/dangling-pointer-rust-fr) entre threads.
- **Traits Send/Sync** : Définissent quels types sont sûrs pour le threading.
## Comment l'Ownership et le Borrowing Préviennent les Data Races
Une **data race** survient quand :
- Deux threads accèdent aux mêmes données simultanément.
- Au moins un accès est une écriture.
- Il n'y a pas de synchronisation.
Les règles de Rust rendent les data races impossibles dans le code safe :
### 1. Mutabilité exclusive (`&mut T`)
- Seule une référence mutable (`&mut T`) peut exister à la fois, appliquée par le [borrow checker](https://mayorana.ch/fr/blog/borrowing-rules-rust-fr).
- Ceci prévient plusieurs threads d'écrire aux mêmes données simultanément.
**Exemple** :
```rust
let mut data = 0;
let r1 = &mut data; // OK: Mutable borrow
// let r2 = &mut data; // ERREUR: Cannot borrow `data` as mutable more than once
```
### 2. Pas de mutabilité partagée Sans synchronisation
- Les références partagées (`&T`) sont read-only, sûres pour l'accès concurrent.
- Pour muter des données partagées, des primitives de synchronisation comme `Mutex` sont requises :
**Exemple** :
```rust
use std::sync::Mutex;
let shared = Mutex::new(42);
let guard = shared.lock().unwrap(); // Accès exclusif
*guard += 1; // Mutation sûre
```
## Types Thread-Safe : Send et Sync
- **Send** : Un type peut être transféré sûrement entre threads (ex : `String`, `Mutex`).
- **Sync** : Un type peut être partagé sûrement entre threads via des références (ex : `&i32`, `Arc`).
**Exemple : Spawning Threads** :
```rust
use std::thread;
let value = String::from("hello"); // `String` est `Send`
thread::spawn(move || { // `move` transfère ownership
println!("{}", value); // Sûr: aucun autre thread ne peut accéder `value`
}).join().unwrap();
```
## Outils de concurrence courants
| **Outil** | **But** | **Mécanisme de Thread Safety** |
|-----------|---------|--------------------------------|
| `Mutex` | Exclusion mutuelle | Locks pour accès exclusif |
| `Arc` | Atomic reference counting | Ownership partagée entre threads |
| `RwLock` | Read-write lock | Lecteurs multiples ou un écrivain |
| `mpsc channels` | Message passing | Transfère ownership entre threads |
**Exemple : État Partagé avec Arc + Mutex** :
```rust
use std::sync::{Arc, Mutex};
use std::thread;
let counter = Arc::new(Mutex::new(0));
let mut handles = vec![];
for _ in 0..10 {
let counter = Arc::clone(&counter);
handles.push(thread::spawn(move || {
let mut num = counter.lock().unwrap();
*num += 1; // Mutex assure accès exclusif
}));
}
for handle in handles {
handle.join().unwrap();
}
println!("Result: {}", *counter.lock().unwrap()); // Affiche 10
```
## Pourquoi C'est important
- **Pas d'overhead runtime** : Les vérifications de sécurité se produisent au moment de la compilation.
- **Pas de garbage collector** : Concurrence sûre sans pauses GC.
- **Parallélisme sans peur** : Le compilateur rejette les patterns unsafe, permettant une programmation concurrente confiante.
## Points clés
**Les règles d'ownership préviennent** :
- L'accès mutable concurrent (pas de data races).
- Les dangling references (via lifetimes).
**Send/Sync appliquent** la thread safety au moment de la compilation.
**Utilise `Mutex`, `Arc`, ou channels** pour un état partagé sûr.
**Impact Réel** : Les crates comme `rayon` (iterators parallèles) et `tokio` (runtime async) s'appuient sur ces garanties pour une concurrence robuste.
Essaie d'envoyer un `Rc` vers un autre thread et le compilateur t'arrête : `Rc` n'est pas
`Send`, parce que son compteur n'est pas atomique. `Arc` a la même forme avec le compteur
atomique, et tu paies pour ça à chaque clone.