Comment weakCompareAndSet peut-il échouer faussement s'il est implémenté exactement comme compareAndSet?

Question

(Notez que cette question ne concerne pas CAS, il s'agit de la "Peut échouer faussement" Javadoc).

La seule différence dans la Javadoc entre ces deux méthodes de la classe AtomicInteger est que le weakCompareAndSet contient le commentaire: « peut échouer spuriously ».

Maintenant, à moins que mes yeux sont floués par un sort, les deux méthode ne semblent être en train de 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); 
} 

Alors je me rends compte que « mai » ne signifie pas « doit », mais alors pourquoi ne « t nous commençons à ajouter ceci à notre base de code:

public void doIt() { 
    a(); 
} 

/** 
* May fail spuriously 
*/ 
public void weakDoIt() { 
    a(); 
} 

Je suis vraiment confondu avec celui weakCompareAndSet() qui semble faire la même chose que le compareAndSet() encore que « peut échouer spuriously » tandis que l'autre ne le peut pas.

Apparemment, le "faible" et le "faux échec" sont en quelque sorte liés à la commande "arrive avant" mais je suis encore très confus par ces deux méthodes AtomicInteger (et AtomicLong etc.): appelez exactement les mêmes unsafe.compareAndSwapInt méthode.

Je suis particulièrement confus dans cette AtomicInteger en Java ai été présenté 1.5, après le changement de modèle Java Memory (il est donc évidemment pas quelque chose qui pourrait « fail 1.4 dans spuriously » mais dont le comportement changé « doit pas échouer faussement dans 1.5 ").

Answer 1

Il y a une différence entre la mise en œuvre et la spécification ...

Alors que sur une mise en œuvre particulière, il ne peut pas être beaucoup d'intérêt à fournir différentes implémentations, les implémentations futures peut-être sur un matériel différent peut vouloir. Si cette méthode porte son poids dans l'API est discutable.

Les méthodes weak ne possèdent pas non plus de happen-before définie par ordre. Les versions non weak se comportent comme des champs volatile.

Answer 2

Juste pour jouer un peu, si votre question était

Comment peut-weakDoIt échouer si elle est fallacieuse mis en œuvre exactement comme doIt?

voici la réponse!

public void doIt() { 
    a(); 
} 

/** 
* May fail spuriously 
*/ 
public void weakDoIt() { 
    a(); 
} 

void a(){ 
    if(Thread.currentThread().getStackTrace()[2].toString().contains("weakDoIt")) 
     System.out.println("I will fail spuriously!"); 
    else System.out.println("I won't fail spuriously!"); 
}