Краткий ответ

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

Исторический контекст

Rust предотвращает классические гонки данных с помощью владения, заимствований и маркеров Send и Sync. Это решает проблему небезопасного одновременного доступа к памяти, характерную для низкоуровневых многопоточных программ.

Однако корректность многопоточной программы шире безопасности памяти. Приложение может использовать только безопасные типы и синхронизацию, но всё равно неправильно реализовать последовательность операций над несколькими связанными состояниями.

Постановка проблемы

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

В результате программа не получит data race или неопределённое поведение, но может разрешить две операции, которые вместе превышают доступный лимит. Mutex защищает участок кода, а не автоматически весь бизнес-инвариант.

Подробное решение

Send означает, что владение значением можно передать другому потоку. Sync означает, что несколько потоков могут безопасно иметь общие ссылки на значение; формально это связано с тем, что &T является Send, когда T реализует Sync.

Эти свойства описывают допустимость доступа к памяти, но не атомарность составной операции. Проверка условия, изменение одного поля и изменение другого поля должны выполняться под единой синхронизацией, если между ними существует общий инвариант.

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

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

fn reserve(available: &Mutex<u32>, reserved: &Mutex<u32>) {
    let enough = *available.lock().unwrap() >= 60;
    if enough {
        *available.lock().unwrap() -= 60;
        *reserved.lock().unwrap() += 60;
    }
}

fn main() {
    let state = Arc::new((Mutex::new(100), Mutex::new(0)));
    let _ = thread::spawn(move || reserve(&state.0, &state.1));
}

Оба потока могут увидеть 100, после чего каждый выполнит резервирование. Исправление состоит не в добавлении новых маркеров, а в выборе правильной гранулярности блокировки: например, объединить связанные поля в одну структуру и менять её под одним Mutex.

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

Ситуация из практики

В платёжном сервисе баланс и список резервов сначала защищали отдельными mutex. Это уменьшало время удержания каждой блокировки, но между проверкой баланса и созданием резерва другой запрос мог выполнить такую же проверку.

Рассматривались три варианта: оставить отдельные блокировки, применить атомики или объединить состояние. Атомики были бы уместны для простого независимого счётчика, но не для транзакционного изменения нескольких структур; отдельные mutex требовали сложного протокола блокировок.

Выбрали одну блокировку вокруг состояния счёта и резерва. Это несколько снизило параллелизм операций над одним счётом, зато сделало проверку и изменение неделимыми, устранило превышение лимита и упростило доказательство корректности.

Что кандидаты часто упускают

1. Может ли логическая гонка существовать при использовании Mutex?

Да. Mutex предотвращает одновременный доступ к защищённым данным, но не объединяет автоматически несколько последовательных захватов в одну атомарную операцию. Если поток читает значение, освобождает mutex, а затем позже изменяет его, другой поток может изменить состояние между этими действиями.

2. Решит ли замена Mutex на атомарную переменную любую логическую гонку?

Нет. Атомарность отдельной загрузки или записи не делает атомарной последовательность «прочитать — проверить — изменить». Для такой операции нужны атомарные read-modify-write, например compare-and-exchange, либо более высокоуровневая синхронизация, которая защищает весь инвариант.

3. Почему тип, реализующий Send и Sync, всё равно может требовать документации по потокобезопасному использованию?

Маркеры описывают безопасность передачи и совместного доступа к памяти, но не семантические ограничения API. Тип может быть memory-safe при любом порядке вызовов, однако корректный результат требовать определённой последовательности операций, единственного владельца логического ресурса или внешней координации. Эти условия должны обеспечиваться API, типовой системой или документацией, а не самими маркерами.

Гарантируют ли маркеры Send и Sync отсутствие логических гонок в многопоточном Rust?