Antwort

Die Standardbibliothek von Rust bietet die grundlegenden Synchronisierungsprimitive für sicheres Arbeiten mit Multithreading:

• Mutex — sorgt für gegenseitigen Ausschluss beim Zugriff auf Daten aus mehreren Threads;
• RwLock — erlaubt gleichzeitig mehrere Leser (read), aber nur einen Schreiber (write);
• Condvar — ein primitives Bedingungsvariable zur Organisation des Weckens von Threads durch ein Ereignis;
• Atomare Typen (AtomicBool, AtomicUsize usw.) — Lese-/Schreiboperationen ohne Sperren auf Hardwareebene;
• Arc (Atomic Reference Counted) — Referenzzählung mit Thread-Sicherheit für gemeinsames Besitzen von Objekten.

Auswahl:

• Wenn gleichzeitig nur Lesen erforderlich ist — verwenden Sie RwLock (effizienter als Mutex).
• Für den einfachen synchronisierten Zugriff eines Threads — Mutex.
• Für die Synchronisation nach Signal (z.B. „auf neues Element warten“) — Condvar.
• Für atomare Zähler/Fahnen — Atomic.
• Für gemeinsames Besitzen (multithreaded) — Arc.

Beispiel:

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

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

    for _ in 0..10 {
        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();
    }

    println!("Result: {}", *counter.lock().unwrap());
}

Fangfrage

Frage: Garantiert Rust, dass die Verwendung von Mutex<T> vollständig von Deadlocks befreit, durch Überprüfung zur Kompilierzeit?

Antwort: Nein. Rust gewährleistet einen sicheren Zugriff auf Daten durch Besitz und Borrow-Checker, schützt jedoch nicht auf Sprachebene vor Deadlocks. Deadlocks entstehen rein logisch durch das Brechen der Reihenfolge beim Erwerb mehrerer Mutex oder deren rekursiven Erwerb. Beispiel:

use std::sync::Mutex;
let lock1 = Mutex::new(0);
let lock2 = Mutex::new(0);
// Thread 1: lock1 -> lock2, Thread 2: lock2 -> lock1 ⇒ deadlock

---

Geschichte

Ein Projekt zur Datenverarbeitung hatte sporadische "Hänger". Es stellte sich heraus, dass die Entwickler verschachtelte Mutex (Mutex innerhalb von Mutex) ohne strikte Erwerbsreihenfolge verwendet hatten, was zu gegenseitigen Sperren (deadlocks) führte, die nur durch einen erzwungenen Prozessabbruch aufgehoben werden konnten.

Geschichte

In einem großen Dienst migrierten sie massenhaft von Mutex<Option<T>> zu RwLock<T>, ohne zu berücksichtigen, dass das schreibbare Lock länger dauern kann als das Leselock. Bei Spitzenlast führte dies zu Verarbeitungsverzögerungen von bis zu Sekunden aufgrund von Warteschlangen beim Schreiben.

Geschichte

Programmierer versuchten, bei Threads zu sparen, und "drückten" Arc<Mutex<_>> in Hunderte von Threads. Aufgrund der Feinheiten der Planerarbeit und der Wiederverwendung von Mutex traten erstaunliche gegenseitige Erwartungen auf — die Leistung verringerte sich um das Fünffache!