ClassValue.Remove(Class) Método

[Android.Runtime.Register("remove", "(Ljava/lang/Class;)V", "GetRemove_Ljava_lang_Class_Handler", ApiSince=34)]
public virtual void Remove(Java.Lang.Class? type);

[<Android.Runtime.Register("remove", "(Ljava/lang/Class;)V", "GetRemove_Ljava_lang_Class_Handler", ApiSince=34)>]
abstract member Remove : Java.Lang.Class -> unit
override this.Remove : Java.Lang.Class -> unit

Parâmetros

Atributos

RegisterAttribute

Comentários

Remove o valor associado para a classe fornecida. Se esse valor for posteriormente #get lido para a mesma classe, seu valor será reinicializado invocando seu #computeValue computeValue método. Isso pode resultar em uma invocação adicional do computeValue método para a classe fornecida.

Para explicar a interação entre get e remove chamadas, devemos modelar as transições de estado de um valor de classe para levar em conta a alternância entre estados não inicializados e inicializados. Para fazer isso, numerar esses estados sequencialmente de zero e observar que os estados não inicializados (ou removidos) são numerados com números pares, enquanto os estados inicializados (ou inicializados novamente) têm números ímpares.

Quando um thread T remove um valor de classe no estado 2N, nada acontece, pois o valor da classe já está não inicializado. Caso contrário, o estado será avançado atomicamente para 2N+1.

Quando um thread T consulta um valor de classe no estado 2N, o thread primeiro tenta inicializar o valor da classe para o estado 2N+1 invocando computeValue e instalando o valor resultante.

Quando T tentar instalar o valor computado recentemente, se o estado ainda estiver em 2N, o valor da classe será inicializado com o valor computado, avançando-o para o estado 2N+1.

Caso contrário, se o novo estado for par ou ímpar, T descartará o valor computado recentemente e repetirá a get operação.

Descartar e tentar novamente é uma proviso importante, pois de outra forma T poderia potencialmente instalar um valor desastrosamente obsoleto. Por exemplo: <ul><li>T chama CV.get(C) e vê o estado 2N<li>T calcular rapidamente um valor V0 dependente de tempo e se prepara para instalá-lo <li>T é atingido por um evento de paginação ou agendamento azarado, e vai dormir por um longo tempo <li...> enquanto isso, T2 também chama CV.get(C) e vê o estado 2N<li>T2 calcular rapidamente um valor V1 dependente de tempo semelhante e instalá-lo em CV.get(C)<li>T2 (ou em um terceiro thread), em seguida, chamadasCV.remove(C), desfazer T2o trabalho <de 's li> as ações anteriores são T2 repetidas várias vezes <li> também, os valores computados relevantes mudam ao longo do tempo: V1, , ... V2<li>... enquanto isso, T acorda e tenta instalarV0; <em>isso deve falhar</em></ul> Podemos supor no cenário acima que CV.computeValue usa bloqueios para observar corretamente os estados dependentes V1de tempo à medida que ele computa, etc. Isso não remove a ameaça de um valor obsoleto, pois há uma janela de tempo entre o retorno de computeValue entrada T e a instalação do novo valor. Nenhuma sincronização de usuário é possível durante esse tempo.

Java documentação para java.lang.ClassValue.remove(java.lang.Class<?>).

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Android Open Source Project e usadas de acordo com os termos descritos na Licença de Atribuição Creative Commons 2.5.