O que significa "falha espúria" na AtomicInteger weakCompareAndSet significa?

votos
17

A classe Java AtomicInteger tem um método -

boolean weakCompareAndSet(int expect,int update)

Sua documnentation diz:

Pode falhar spuriously.

O que significa 'não spuriously' aqui significa?

Publicado 10/12/2008 em 08:44
fonte usuário
Em outras línguas...                            


4 respostas

votos
18

spuriously: sem razão aparente

De acordo com atomicjavadoc pacote:

As classes atômicas também suportam método weakCompareAndSet, que tem aplicabilidade limitada.

Em algumas plataformas, a versão fraca pode ser mais eficiente do que compareAndSet no caso normal, mas difere em que qualquer invocação do método weakCompareAndSet pode retornar false spuriously (isto é, sem razão aparente ).

Um falso retorno significa apenas que a operação pode ser repetida se desejado, contando com a garantia de que repetida invocação quando a variável contém expectedValue e nenhum outro segmento também está tentando definir a variável irá suceder.
(Tais falhas espúrios podem ser, por exemplo, devido a efeitos de contenção de memória que não estão relacionados com se os valores esperados e os actuais são iguais).

Além disso weakCompareAndSet não fornece encomendar garantias que são normalmente necessários para o controle de sincronização.


De acordo com esta discussão , não é tanto por causa de "hardware / OS", mas por causa do algoritmo subjacente usado por weakCompareAndSet:

weakCompareAndSet atomicamente define o valor para o determinado valor atualizado se o valor atual == o valor esperado . Pode falhar spuriously.

Ao contrário compareAndSet (), e outras operações em um AtomicX, a operação weakCompareAndSet () não cria qualquer orderings acontece-antes .

Assim, apenas porque um segmento vê uma atualização para um AtomicX causada por um weakCompareAndSet não significa que ele está devidamente sincronizado com as operações que ocorreram antes da weakCompareAndSet ().

Você provavelmente não quer usar esse método, mas em vez disso deve apenas usar compareAndSet; como existem poucos casos em que weakCompareAndSet é mais rápido do que compareAndSet, e há uma série de casos em que tentando otimizar seu código usando weakCompareAndSet em vez de compareAndSet irá introduzir sutil e difícil de reproduzir erros de sincronização em seu código.


Nota sobre acontece-antes ordenações :

O modelo de memória Java (JMM) define as condições em que um fio de ler uma variável é garantido para ver os resultados de uma gravação em outro segmento.

A JMM define uma ordenação sobre as operações de um programa chamado acontece-antes.

Acontece-antes ordenações entre segmentos são criados apenas sincronizando em um bloqueio comum ou acessar uma variável volátil comum.

Na ausência de uma ordenação acontece-antes, a plataforma Java tem grande latitude para atrasar ou alterar a ordem em que escreve em um segmento se tornam visíveis para lê dessa mesma variável em outro.

Respondeu 10/12/2008 em 09:05
fonte usuário

votos
6

Um bom caso de uso para weakCompareAndSet é contadores de desempenho - sem necessidade de ordenação, alta taxa de atualizações (assim ordenação dói em sistemas fracamente encomendados), mas não vai cair contagem sob altas cargas (firmemente perf-contadores contentes pode cair de 99% de todos conta, essencialmente, deixando os contadores valor relativo a contadores sustentou-un aleatórios).

Respondeu 13/12/2013 em 22:59
fonte usuário

votos
6

Isso significa que ele pode retornar falso (e não irá definir o novo valor), mesmo que atualmente contém o valor esperado.

Em outras palavras, o método pode fazer nada e retornar falso, sem motivo aparente ...
Há arquiteturas de CPU onde isso pode ter uma vantagem de desempenho sobre um forte CompareAndSet().


detalhe Um pouco mais concreto sobre por que algo como isso poderia acontecer.

Algumas arquiteturas (como braços mais recentes) implementar operações CAS usando um conjunto de instruções de carga Linked (LL) / loja Condicional (SC). A instrução LL carrega o valor em um local de memória e 'lembra' o endereço em algum lugar. A instrução SC armazena um valor em que local da memória se o valor no endereço lembrado não foi modificado. É possível que o hardware para acreditar que o local foi modificado, mesmo que, aparentemente, não tem para um número de razões possíveis (e as razões podem variar de acordo com a arquitetura CPU):

  1. o local pode ter sido escrito com o mesmo valor
  2. a resolução dos endereços assistiram pode não ser exatamente o local uma memória de interesse (pense linhas de cache). A gravação para outro local que é 'bem perto' pode fazer com que o hardware para sinalizar o endereço em questão como 'suja'
  3. uma série de outras razões que podem fazer com que o CPU a perder o estado salvo da instrução LL - trocas de contexto, liberações do cache, ou alterações de tabela de página talvez.
Respondeu 10/12/2008 em 08:51
fonte usuário

votos
0

Mas por que tal permissão para ocorrer em tudo? É este, pois o hardware / OS embaixo é buggy? Ou há alguma boa razão técnica por trás disso?

Respondeu 10/12/2008 em 14:18
fonte usuário

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