Что означает "ложный отказ" от AtomicInteger weakCompareAndSet?

Ответ 1

ложно: без видимых причин

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

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

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

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

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

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

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

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

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

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

Примечание относительно происходит перед заказами:

Модель памяти Java (JMM) определяет условия, при которых поток, читающий переменную, может видеть результаты записи в другом потоке.

JMM определяет порядок операций над программой, которая называется before-before.

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

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

Ответ 2

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

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

Более подробная информация о том, почему может произойти что-то подобное.

Некоторые архитектуры (например, новые ARM) реализуют операции CAS с использованием набора инструкций Load Linked (LL)/Store Conditional (SC). Команда LL загружает значение в ячейку памяти и "где-то запоминает" адрес. Инструкция SC хранит значение в этой ячейке памяти, если значение на запоминаемом адресе не было изменено. Возможно, аппаратное обеспечение полагает, что местоположение было изменено, даже если оно, по-видимому, не по ряду возможных причин (и причины могут варьироваться в зависимости от архитектуры процессора):

• местоположение может быть записано с тем же значением
• Разрешение просматриваемых адресов может быть не только в том месте, где находится память, а в том, что касается кэширования. Запись в другое место, которое "близко" может привести к тому, что аппаратное обеспечение будет помечать указанный адрес как "грязный"
• ряд других причин, которые могут привести к тому, что CPU потеряет сохраненное состояние команды LL - возможно, будут переключаться контекстные переключатели, сбросы кешей или изменения таблицы страниц.

Ответ 3

Хорошим вариантом использования для weakCompareAndSet являются счетчики производительности - нет необходимости в заказе, высокой скорости обновлений (так что у вас болит на слабо упорядоченных системах), но не будет снижать количество баллов при высоких нагрузках (плотно доработанные перфокаторы могут сбросить 99 % от всех отсчетов, по существу оставляя значение счетчиков относительно случайных несогласных счетчиков случайным).

Ответ 4

Но почему такое разрешено вообще? Это потому, что аппаратное обеспечение/ОС под ошибкой? Или есть какая-то хорошая техническая причина?