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

голоса
17

Класс Java AtomicInteger имеет метод -

boolean weakCompareAndSet(int expect,int update)

Его documnentation говорит:

Может терпеть неудачу поддельно.

Что значит «провал поддельно» здесь означает?

Задан 10/12/2008 в 08:44
источник пользователем
На других языках...                            


4 ответов

голоса
18

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

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

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

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

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

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


По этой теме , это не столько из - за «аппаратного / OS», но из - за базового алгоритма , используемого weakCompareAndSet:

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

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

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

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


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

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

JMM определяет упорядочение на операции программы называется происходит-прежде.

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

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

Ответил 10/12/2008 в 09:05
источник пользователем

голоса
6

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

Ответил 13/12/2013 в 22:59
источник пользователем

голоса
6

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

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


Немного более конкретные детали о том, почему что-то подобное может произойти.

Некоторые архитектуры (как новое ОРУЖИЕ) осуществлять операции CAS с использованием нагрузки Linked (LL) / магазин Условный (SC) набором инструкций. Инструкция LL загружает значение в ячейке памяти и «запоминает» адрес где-то. Инструкция SC сохраняет значение в эту ячейку памяти, если значение в запоминаемом адресе не было изменено. Это возможно для аппаратных средств верить, что местоположение было изменено, даже если он, по-видимому не имеет для целого ряда возможных причин (и причины могут варьироваться в зависимости от архитектуры процессора):

  1. место, возможно, было написано с тем же значением
  2. разрешение адресов отслеживаемых не может быть точно местом одна памяти интереса (вспомнит строку кэша). Запись в другое место, это «близко от» может привести к аппаратным средствам флага адреса в вопросе, как «грязный»
  3. ряд других причин, которые могут привести к CPU терять сохраненное состояние команды LL - контекстные переключатели, промывает кэш, или изменения таблицы страниц возможны.
Ответил 10/12/2008 в 08:51
источник пользователем

голоса
0

Но почему такие позволено произойти вообще? Является ли это потому, что аппаратное обеспечение / OS под глючит? Или есть хорошая техническая причина этого?

Ответил 10/12/2008 в 14:18
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more