(notez que cette question n'est pas sur les CAS, c'est sur le "risque de ne pas faussement" Javadoc).
La seule différence dans la Javadoc entre ces deux méthodes à partir de l' AtomicInteger classe est que le weakCompareAndSet contient le commentaire: "Peut échouer injustifiées".
Maintenant, à moins que mes yeux sont trompés par certains sorts, à la fois la méthode ne semble faire exactement la même chose:
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
/* ...
* May fail spuriously.
*/
public final boolean weakCompareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
Si je me rends compte que "Peut" ne signifie pas "Doit", mais alors, pourquoi n'avons-nous pas tous commencer à ajouter à notre base de code:
public void doIt() {
a();
}
/**
* May fail spuriously
*/
public void weakDoIt() {
a();
}
Je suis vraiment confus avec ce weakCompareAndSet() qui semble faire la même chose que le compareAndSet() mais qui "risque de ne pas se faire une idée fausse", tandis que les autres ne le peuvent pas.
Apparemment, les "faibles" et les "fausses fail" sont en quelque sorte liés à la "passe-avant" la commande mais je suis encore très confus par ces deux AtomicInteger (et AtomicLong etc.) méthodes: car, apparemment, ils appellent exactement la même dangereux.compareAndSwapInt méthode.
Je suis particulièrement confus en ce qu' AtomicInteger était introduit dans Java 1.5, donc après la Mémoire Java changement de Modèle (il n'est évidemment pas quelque chose qui pourrait "tomber par erreur dans la version 1.4," mais dont le comportement a changé à "ne doit pas échouer faussement en 1,5").
