2 fils EFFECTUER myAtomicReference.compareAndSet (attendus, nouvelle date())

Question

static boolean unsynchronizedSetter(Date expected){ 
    Date newDate = new Date(); 
    AtomicReference<Date> myAtomicReference = Lookup.getAtomicRef(); 
    boolean myStatus = myAtomicReference.compareAndSet(expected, newDate); //CAS 
    return myStatus; 
} 

Q: Si 2 fils exécute, quel objet sera enregistrés dans le répertoire de référence atomique?

Dans une machine multiprocesseur, 2 threads peuvent effectuer le CAS dans le même cycle d'horloge. Supposons qu'ils utilisent tous les deux le même objet myAtomicReference pour faire le CAS, tous les deux utilisent la valeur correcte de "expected", mais ils essaient de mettre en 2 objets distincts, à savoir le 2 newDate. L'un d'eux doit échouer, mais myStatus sera-t-il faux dans ce fil?

Je suppose qu'une implémentation matérielle de CompareAndSwap ferait en sorte que les threads se mettent en file d'attente pour faire leurs mises à jour. Je suppose que même si les deux processeurs exécutent l'instruction CAS dans le même cycle d'horloge, l'un d'eux est probablement retardé.

Answer 1

Q: If 2 threads executes it, which object will get stored in the atomic reference? 

Personne ne peut le savoir. Selon le javadoc, l'un d'entre eux. AFAIK, il n'y a pas d'horloge globale pour les processeurs multicœurs Intel/AMD actuels.

One of them must fail, but will myStatus be false in that thread? 

Il doit être, sinon ce serait dire qu'il a réussi et l'ensemble java.util.concurrent tomberait en morceaux. Je suis tout à fait sûr, que myStatus dans un thread doit être faux même si les deux ont essayé d'y mettre le même objet.

I guess one hardware implementation of CompareAndSwap would make the threads queue up to do their updates. 

Je ne dirais pas « font la queue » (cela ressemble à quelque chose fait par le système d'exploitation), l'instruction CAS sera retardée par le matériel.

Answer 2

Merci pour l'entrée. Comme le questionneur d'origine, je me sens maintenant il est possible que myStatus == true dans les deux fils - c'est ma tentative de réponse à ma question ci-dessous

"One of them must fail, but will myStatus be false in that thread?" 

Il est concevable, à mon humble avis, que les deux fils « pensent » qu'ils ont réussi à mettre dans leur objet newDate respectif. Cependant, le premier thread devrait savoir que sa variable myStatus est désespérément peu fiable tout le temps, juste après l'opération CAS. Ce n'est pas fiable parce que myStatus pourrait être vrai, mais quand vous lisez le AtomicReference, la valeur pourrait avoir changé. La classe AtomicReference partagée est susceptible d'être modifiée à tout moment par n'importe quel thread. Cette instance AtomicReference n'est protégée par aucune construction de synchronisation. Cela signifie seulement que ce thread avait une estimation correcte de la valeur expected, donc JVM doit lui donner le prix promis pour la bonne estimation. Cependant, JVM ne conservera pas la nouvelle date dans la référence atomique. Donc gagner ce "prix" ne veut rien dire.

J'espère que cela a du sens.