ClassValue.Remove(Class) Metodo

[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

Parametri

Attributi

RegisterAttribute

Commenti

Rimuove il valore associato per la classe specificata. Se questo valore viene successivamente #get letto per la stessa classe, il relativo valore verrà reinizializzato richiamando il relativo #computeValue computeValue metodo. Ciò può comportare una chiamata aggiuntiva del computeValue metodo per la classe specificata.

Per spiegare l'interazione tra get e remove chiamate, è necessario modellare le transizioni di stato di un valore di classe per tenere conto dell'alternanza tra stati non inizializzati e inizializzati. A tale scopo, numerare questi stati in sequenza da zero e notare che gli stati non inizializzati (o rimossi) sono numerati con numeri pari, mentre gli stati inizializzati (o reinizializzati) hanno numeri dispari.

Quando un thread T rimuove un valore di classe nello stato 2N, non accade nulla, poiché il valore della classe è già non inizializzato. In caso contrario, lo stato è avanzato in modo atomico a 2N+1.

Quando un thread T esegue una query su un valore di classe nello stato , il thread tenta prima di tutto di inizializzare il valore della classe in modo che sia impostato sullo stato 2N2N+1 richiamando computeValue e installando il valore risultante.

Quando T tenta di installare il valore appena calcolato, se lo stato è ancora in 2N, il valore della classe verrà inizializzato con il valore calcolato, passandolo allo stato 2N+1.

In caso contrario, se il nuovo stato è pari o dispari, T scarterà il valore appena calcolato e ritentare l'operazione get .

L'eliminazione e la ripetizione di tentativi è un proviso importante, perché T altrimenti potrebbe installare un valore disastrosamente obsoleto. Ad esempio: <ul><li>T chiama CV.get(C) e vede lo stato2N< li>T calcola rapidamente un valore V0 dipendente dal tempo e si prepara a installarlo <è>T colpito da un evento di paging o pianificazione sfortunato, e passa a dormire per molto tempo <li...> nel frattempo, T2 chiama CV.get(C) e vede anche state2N< li calcola rapidamente un valore > dipendente dal tempo simile e lo installa su T2V1liCV.get(C)< (o un terzo thread), quindi chiama >, annullando T2il lavoro CV.remove(C)T2 di li<> le azioni precedenti di T2 vengono ripetute più volte <anche li>, i valori calcolati pertinenti cambiano nel tempo: V1, V2, ... <li>... nel frattempo, T si sveglia e tenta di installare V0; <em>this must fail</em></ul> We can assume in the above scenario that CV.computeValue uses locks to properly observe the time-dependent states as it computes V1, etc. In questo modo non viene rimossa la minaccia di un valore non aggiornato, poiché esiste un intervallo di tempo tra la restituzione di computeValue in T e l'installazione del nuovo valore. Durante questo periodo non è possibile eseguire alcuna sincronizzazione utente.

per java.lang.ClassValue.remove(java.lang.Class<?>).

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dalla e usati in base ai termini descritti in Creative License 2.5 Attribution License.