Nebenläufigkeit

Rust Mutex Design

In einigen Concurrency-APIs ist ein Mutex von den Daten getrennt, die er schützt. Stellen Sie sich zum Beispiel eine hypothetische Mutex-API wie diese vor:

let mut data = Vec::new();
let mx: Mutex = Mutex::new();
{
    let _guard = mx.lock();
    data.push(0);
}

Welche der folgenden Aussagen beschreibt am besten, warum Rust Mutex<T> anstelle von nur Mutex verwendet?

1. Um die Effizienz von nebenläufigen Programmen mit Mutexes zu verbessern

2. Um den Zugriff auf die Daten eines Mutex ohne Sperren des Mutex zu verhindern

3. Um weniger Aufrufe von Mutex-Methoden zu erfordern

4. Um zu verhindern, dass die Daten eines Mutex zwischen Threads verschoben werden

Prüfen

Das Design von Mutex<T> stellt sicher, dass die Daten eines Mutex nur zugänglich sind, wenn der Mutex gesperrt ist, und umgekehrt, dass der Mutex entsperrt wird, sobald die Daten nicht mehr zugänglich sind.

---

Arc und Referenz-Lebensdauer

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

fn main() {
    let s = String::from("Hello world");
    let a = Arc::new(&s);
    let a2 = Arc::clone(&a);
    let t = thread::spawn(move || a2.len());
    let len = t.join().unwrap();
    println!("{} {}", a, len);
}

1. Kompiliert
2. Kompiliert nicht

Prüfen

Ein Arc ist immer noch nicht sicher zu verwenden, wenn seine Daten eine Referenz enthalten, da die Referenz (theoretisch) ungültig werden könnte, bevor alle Threads, die den Arc enthalten, ihre Ausführung beenden.

---