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

Слабое сравнение с обменом (compare_exchange_weak) может вернуть отказ даже тогда, когда атомарное значение не изменилось. Поэтому его применяют внутри цикла повторной попытки: ложный отказ просто приводит к следующей итерации, а на некоторых архитектурах такая форма операции эффективнее сильной.

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

Lock-free-алгоритмы используют атомарное сравнение с обменом (CAS), чтобы условно заменить значение без блокировки mutex. Аппаратная реализация CAS различается: на одних архитектурах операция выполняется непосредственно, а на других строится на примитивах загрузки и условного сохранения, которые могут завершаться неуспешно без фактического изменения значения.

compare_exchange_weak предоставляет реализации право сообщить о таком ложном отказе. Это позволяет эффективнее отображать операцию на разные процессорные механизмы, не меняя модель корректности Rust.

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

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

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

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

Цикл загружает текущее значение и пытается заменить его новым. При реальном конфликте или ложном отказе операция повторяется; при успехе обновление считается выполненным.

use std::sync::atomic::{AtomicUsize, Ordering};

fn increment(value: &AtomicUsize) {
    let mut old = value.load(Ordering::Relaxed);
    loop {
        match value.compare_exchange_weak(
            old, old + 1, Ordering::Relaxed, Ordering::Relaxed
        ) {
            Ok(_) => return,
            Err(actual) => old = actual,
        }
    }
}

При конфликте Err возвращает фактическое значение атомика, и оно становится новым ожидаемым значением. При ложном отказе фактическое значение может совпадать с прежним ожидаемым, но цикл всё равно безопасно повторяет попытку.

Сильная форма (compare_exchange) не допускает ложного отказа: она завершается ошибкой только при несовпадении текущего значения с ожидаемым. Поэтому её удобнее использовать для одиночной попытки, тогда как слабая форма обычно естественна в циклах. Это не означает, что слабая форма всегда быстрее: итог зависит от архитектуры, конкуренции и стоимости повторных итераций.

Порядок памяти — отдельная часть решения. Relaxed гарантирует атомарность самого счётчика, но не публикует связанные обычные данные между потоками. Для передачи состояния обычно требуется Release при успешной записи и Acquire при соответствующем чтении; порядок неуспешной попытки также должен соответствовать ограничениям API.

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

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

Если же операция выполняется только один раз, например попытка захватить ресурс без ожидания, слабая форма может вернуть отказ без реального конфликта и потребовать дополнительной логики. В таком сценарии сильный CAS обычно проще для рассуждения; в цикле обновления выбран слабый CAS, потому что повторная попытка уже является частью алгоритма.

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

Может ли слабый CAS завершиться ошибкой, если значение действительно не менялось?

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

Гарантирует ли успешный CAS синхронизацию связанных данных?

Не автоматически. CAS является атомарной операцией, но вид синхронизации определяется выбранным Ordering. Успешный CAS с Relaxed не устанавливает межпоточный порядок для обычных записей; он подходит для независимого счётчика, но недостаточен для публикации объекта или его содержимого.

Почему простого сравнения адреса или числа иногда недостаточно из-за ABA-проблемы?

CAS проверяет только, что значение снова равно ожидаемому. Если оно изменилось с A на B, а затем вернулось в A, CAS может не заметить промежуточные изменения и принять устаревшее состояние за неизменившееся.

Для структур, где это существенно, применяют версию вместе со значением, специальные схемы управления временем жизни или другие алгоритмы, предотвращающие повторное использование идентичности. Поэтому корректность lock-free-алгоритма требует анализировать не только порядок памяти и ложные отказы, но и возможность ABA.