Ответ.

История вопроса:

Работа с многопоточностью — источник ошибок в большинстве языков программирования: гонки данных, конкуренция за ресурсы, неочевидные баги. Изучая опыт C++ и Java, создатели Rust решили встроить механизмы безопасности потоков прямо в систему типов, чтобы большинство ошибок выявлялись уже во время компиляции.

Проблема:

В классических языках часто приходится полагаться на дисциплину программиста и внешний инструментарий: риски передачи владения данными, разделяемая изменяемая память и отсутствие контроля за одновременным доступом могут приводить к критическим сбоям. Нужно было обеспечить систему, гарантирующую отсутствие гонок памяти на этапе компиляции.

Решение:

В Rust для синхронизации и передачи данных между потоками используются специальные типы из стандартной библиотеки — например, Arc, Mutex и каналы. Ключевую роль играют маркеры трейтов Send и Sync, которые автоматом проверяются компилятором. Тип считается thread-safe, если:

• только безопасные типы могут быть поделены между потоками (Sync)
• тип можно передать между потоками только если он реализует Send

Пример кода:

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());
}

Ключевые особенности:

• Примитивы синхронизации Mutex, RwLock, каналы — thread-safe по contract'у
• Передача доступа к данным реализуется через типы-обертки (Arc, Mutex), а не через указатели
• Система Send/Sync не позволяет ошибочно поделиться небезопасными структурами между потоками

Вопросы с подвохом.

Почему нельзя использовать Rc<T> для передачи данных между потоками?

Rc<T> не реализует трейт Send и не является потокобезопасным — внутренняя реализация основана на неблокирующем счетчике ссылок, что приводит к гонкам данных при доступе из нескольких потоков. Для потоков используйте Arc<T>.

Можно ли вручную реализовать Send или Sync для собственного типа, чтобы обойти ограничения компилятора?

Можно, но это крайне опасно! Если нарушить инварианты (например, поделиться голым указателем), мы получим гонку данных. Оставьте ручную реализацию только для специалистов, полностью уверенных в thread safety типа.

Когда Mutex может привести к deadlock в Rust, и как это избежать?

Deadlock возможен, если порядок захвата нескольких мьютексов не стабилен или блокировка вложена рекурсивно на одном потоке (Mutex не повторно захватываемый!).

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

Типовые ошибки и анти-паттерны

• Использование Rc вместо Arc для межпоточного доступа
• Хранение mut-ссылок или raw pointers в типах, которые разделяются между потоками
• Забвение проверки unwrap при работе с lock()

Пример из жизни

Негативный кейс

Разработчик использовал Rc<RefCell<T>> для передачи состояния между потоками в веб-сервере. На локальных тестах работало, но на продакшене появились гонки данных: иногда переменные "теряли" состояния, иногда сервер падал.

Плюсы:

• Простой и лаконичный код

Минусы:

• Динамические гонки, краши, неустранимые баги, уязвимости по безопасности

Позитивный кейс

Использование Arc<Mutex<T>> при передаче состояния, строгое соблюдение Send/Sync, распределение работы по потокам через каналы, никакого mut общих данных в потоках.

Плюсы:

• Rust не даст собрать проект с гонками на этапе компиляции
• Простая диагностика проблем с локациями/отслеживанием данных

Минусы:

• Возникает накладная стоимость на lock/unlock
• Нужно помнить про contention (любые мьютексы могут замедлить конкурентный доступ)