Odpowiedź.

Historia pytania:

Praca z wątkowością jest źródłem błędów w większości języków programowania: wyścigi danych, konkurencja o zasoby, nieoczywiste błędy. Zanalizowawszy doświadczenia C++ i Javy, twórcy Rust postanowili wbudować mechanizmy bezpieczeństwa wątku bezpośrednio w system typów, aby większość błędów była wykrywana już w czasie kompilacji.

Problem:

W klasycznych językach często trzeba polegać na dyscyplinie programisty i zewnętrznych narzędziach: ryzyko przekazywania własności danych, współdzielona pamięć zmienna oraz brak kontroli nad równoczesnym dostępem mogą prowadzić do krytycznych awarii. Należało zapewnić system, który gwarantuje brak wyścigów pamięci na etapie kompilacji.

Rozwiązanie:

W Rust do synchronizacji i przekazywania danych między wątkami używane są specjalne typy z biblioteki standardowej — na przykład Arc, Mutex i kanały. Kluczową rolę odgrywają markery traitów Send i Sync, które są automatycznie sprawdzane przez kompilator. Typ jest uważany za bezpieczny wątkowo, jeśli:

tylko bezpieczne typy mogą być dzielone między wątkami (Sync)
typ można przekazać między wątkami tylko wtedy, gdy realizuje Send

Przykład kodu:

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!("Wynik: {}", *counter.lock().unwrap());
}

Kluczowe cechy:

Prymitywy synchronizacji Mutex, RwLock, kanały — są thread-safe według kontraktu
Przekazywanie dostępu do danych realizowane jest przez typy-wrapped (Arc, Mutex), a nie przez wskaźniki
System Send/Sync nie pozwala na błędne dzielenie się niebezpiecznymi strukturami między wątkami

Pytania z pułapką.

Dlaczego nie można używać Rc<T> do przekazywania danych między wątkami?

Rc<T> nie realizuje traitu Send i nie jest thread-safe — wewnętrzna implementacja opiera się na nieblokującym liczniku odniesień, co prowadzi do wyścigu danych przy dostępie z kilku wątków. Dla wątków używaj Arc<T>.

Czy można ręcznie zrealizować Send lub Sync dla własnego typu, aby obejść ograniczenia kompilatora?

Można, ale jest to niezwykle niebezpieczne! Jeśli naruszysz inwarianty (na przykład podzielisz się surowym wskaźnikiem), otrzymasz wyścig danych. Pozostaw ręczną implementację tylko dla specjalistów, którzy są całkowicie pewni bezpieczeństwa wątkowego typu.

Kiedy Mutex może prowadzić do deadlocka w Rust i jak tego uniknąć?

Deadlock jest możliwy, jeśli kolejność przechwytywania wielu mutexów nie jest stabilna lub blokada jest zagnieżdżona rekursywnie w jednym wątku (Mutex nie jest reentrant!).

use std::sync::Mutex;
let a = Mutex::new(0);
let _g1 = a.lock().unwrap();
let _g2 = a.lock().unwrap(); // panic: deadlock!

Typowe błędy i antywzorce

Użycie Rc zamiast Arc do dostępu międzywątkowego
Przechowywanie mut-referencji lub surowych wskaźników w typach, które są dzielone między wątkami
Zapominanie o sprawdzeniu unwrap przy pracy z lock()

Przykład z życia

Negatywny przypadek

Programista użył Rc<RefCell<T>> do przekazywania stanu między wątkami w serwerze WWW. Na lokalnych testach działało, ale na produkcji pojawiły się wyścigi danych: czasami zmienne "traciły" stany, czasami serwer się zawieszał.

Zalety:

Prosty i zwięzły kod

Wady:

Dynamika wyścigów, awarie, nieusuwalne błędy, luki w bezpieczeństwie

Pozytywny przypadek

Użycie Arc<Mutex<T>> przy przekazywaniu stanu, ścisłe przestrzeganie Send/Sync, rozdzielenie pracy między wątki przez kanały, brak mutacji wspólnych danych w wątkach.