Что делает “побочный отказ” на среднем AtomicInteger weakCompareAndSet?

Это означает, что это могло бы возвратить false (и не установит новое значение), даже если это в настоящее время будет содержать математическое ожидание.

, Другими словами, метод ничего не может сделать и возвратить false без видимой причины...
существуют архитектуры ЦП, где это может иметь преимущество производительности перед сильным CompareAndSet().

немного более конкретная деталь о том, почему что-то вроде этого могло бы произойти.

Некоторая архитектура (как более новые РУКИ) реализует операции CAS с помощью Связанной загрузки (LL) / набор Условного выражения хранилища (SC) инструкций. Инструкция LL загружает значение в ячейке памяти и 'помнит' адрес где-нибудь. Инструкция SC хранит значение в ту ячейку памяти, если значение в помнившем адресе не было изменено. Для аппаратных средств возможно полагать, что местоположение было изменено, даже если это, по-видимому, не имеет для многих возможных причин (и причины могли бы варьироваться архитектурой ЦП):

1. местоположение, возможно, было записано с тем же значением
2. , разрешение наблюдаемых адресов не могло бы быть точно одной ячейкой памяти интереса (думайте строки кэша). Запись к другому местоположению, которое это 'рядом', может заставить аппаратные средства отмечать рассматриваемый адрес как 'грязный'
3. много других причин, которые могут заставить ЦП терять сохраненное состояние инструкции LL - контекстные переключения, очистки кэша или изменения таблицы страниц, возможно.

побочно: без видимой причины

Согласно atomic пакет javadoc:

атомарные классы также поддерживают метод weakCompareAndSet, который ограничил применимость.

На некоторых платформах, слабая версия может быть более эффективной, чем compareAndSet в нормальном случае, но отличается по тому , любой данный вызов weakCompareAndSet метода может возвратить false побочно (то есть, без видимой причины ).

ложный возврат А означает только, что операция может быть повторена при желании, полагаясь на гарантию, которая повторила вызов, когда переменная содержит expectedValue, и никакой другой поток также не пытается установить переменную, в конечном счете успешно выполнится.
(Такие побочные отказы могут, например, произойти из-за эффектов нехватки памяти, которые не связаны с тем, равны ли ожидаемые и текущие значения.)

Дополнительно weakCompareAndSet не обеспечивает гарантии упорядочивания, которые обычно необходимы для управления синхронизацией.

Согласно этот поток , это не так из-за "аппаратных средств/ОС", но из-за базового алгоритма, используемого weakCompareAndSet:

weakCompareAndSet атомарно устанавливает значение к данному обновленному значению если текущее значение == математическое ожидание . Может перестать работать побочно.

В отличие от compareAndSet (), и другие операции на AtomicX, weakCompareAndSet () операция не создает никакой , происходит - перед упорядочиваниями .

Таким образом, просто потому что поток видит, обновление AtomicX, вызванного weakCompareAndSet, не означает, что правильно синхронизируется с операциями, которые произошли перед weakCompareAndSet ().

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

Примечание относительно [1 130] происходит - перед упорядочиваниями :