ClassValue.Remove(Class) Méthode

[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

Paramètres

Attributs

RegisterAttribute

Remarques

Supprime la valeur associée pour la classe donnée. Si cette valeur est par la suite #get lue pour la même classe, sa valeur est réinitialisée en appelant sa #computeValue computeValue méthode. Cela peut entraîner un appel supplémentaire de la computeValue méthode pour la classe donnée.

Pour expliquer l’interaction entre get et remove les appels, nous devons modéliser les transitions d’état d’une valeur de classe pour prendre en compte l’alternation entre les états non initialisés et initialisés. Pour ce faire, nombrez ces états séquentiellement de zéro et notez que les états non initialisés (ou supprimés) sont numérotés avec des nombres pairs, tandis que les états initialisés (ou réinitialisés) ont des nombres impairs.

Lorsqu’un thread T supprime une valeur de classe en état 2N, rien ne se produit, car la valeur de classe est déjà non initialisée. Sinon, l’état est avancé atomiquement vers 2N+1.

Lorsqu’un thread T interroge une valeur de classe en état 2N, le thread tente d’abord d’initialiser la valeur de classe à l’état 2N+1 en appelant computeValue et en installant la valeur résultante.

Lorsque vous T tentez d’installer la valeur nouvellement calculée, si l’état est toujours à 2Nl’état, la valeur de classe est initialisée avec la valeur calculée, la faisant passer à l’état 2N+1.

Sinon, si le nouvel état est pair ou impair, T ignore la valeur nouvellement calculée et réessaye l’opération get .

Ignorer et réessayer est un proviso important, car sinon T pourrait installer une valeur obsolète catastrophique. Par exemple : <ul><li>T appelle CV.get(C) et voit l’état 2N<li>T calcule rapidement une valeur V0 dépendante du temps et est prêt à l’installer <est>T atteint par un événement de pagination ou de planification nonucky, et va dormir pendant une longue période <li...> en attendant, T2 aussi appelle CV.get(C) et voit l’état 2N<li>T2 rapidement calcule une valeur V1 dépendante du temps similaire et l’installe surCV.get(C)< li>T2 (ou un troisième thread) puis appelle CV.remove(C), annuler T2le travail <> li les actions précédentes de T2 sont répétées plusieurs fois <li> également, les valeurs calculées pertinentes changent au fil du temps : V1, ... V2<li>... pendant ce temps, T se réveille et tente d’installer V0; <em>ceci doit échouer</em/ul><> Nous pouvons supposer dans le scénario ci-dessus qui CV.computeValue utilise des verrous pour observer correctement les états dépendants du temps pendant qu’il calcule V1, etc. Cela ne supprime pas la menace d’une valeur obsolète, car il existe une fenêtre de temps entre le retour de computeValue la valeur et T l’installation de la nouvelle valeur. Aucune synchronisation utilisateur n’est possible pendant cette période.

Java documentation pour java.lang.ClassValue.remove(java.lang.Class<?>).

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.