如果weakCompareAndSet如果实现完全像compareAndSet，会如何失败？ [英] How can weakCompareAndSet fail spuriously if it is implemented exactly like compareAndSet?

问题描述

（请注意，此问题不是关于CAS的，而是关于可能会失败的错误 Javadoc）。

AtomicInteger 类中这两个方法之间的Javadoc是 weakCompareAndSet 包含注释：May fail spuriously 。

现在除非我的眼睛被某些法术所欺骗，否则这两种方法看起来都是完全一样的：

  public final boolean compareAndSet（int expected，int update）{
 return unsafe.compareAndSwapInt（this，valueOffset，expect，update）; 
} 
 
 / * ... 
 *可能会错误地失败。 
 * / 
 public final boolean weakCompareAndSet（int expected，int update）{
 return unsafe.compareAndSwapInt（this，valueOffset，expect，update）; 
} 
  

所以我意识到May不是Must为什么我们不开始将它添加到我们的代码库：

  public void doIt（）{
a 
} 
 
 / ** 
 *可能失败的错误
 * / 
 public void weakDoIt（）{
 a（）; 
} 
  

我真的很困惑与 weakCompareAndSet >似乎与 compareAndSet（）相同，但可能会失败，而另一个不能。

显然， weak和spurious fail都与happens-before排序有关，但是我仍然非常困惑这两个AtomicInteger（和AtomicLong等）方法：因为显然他们调用完全相同 。

c>在Java 1.5中引入，因此在Java内存模型更改后（因此它显然不是可以在1.4中错误地失败但是其行为更改为的东西不会虚假地

$

解决方案

实施和规范之间有区别...

虽然在一个特定的实现上，提供不同的实现可能没有多少意义，但未来的实现可能在不同的硬件上。此方法是否在API中承载其重量是有争议的。

此外， weak 方法没有发生在之前。非 weak 版本表现为 volatile 字段。

(note that this question is not about CAS, it's about the "May fail spuriously" Javadoc).

The only difference in the Javadoc between these two methods from the AtomicInteger class is that the weakCompareAndSet contains the comment: "May fail spuriously".

Now unless my eyes are cheated by some spell, both method do look to be doing exactly the same:

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);
}

So I realize that "May" doesn't mean "Must" but then why don't we all start adding this to our codebase:

public void doIt() {
    a();
}

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

I'm really confused with that weakCompareAndSet() that appears to do the same as the compareAndSet() yet that "may fail spuriously" while the other can't.

Apparently the "weak" and the "spurious fail" are in a way related to "happens-before" ordering but I'm still very confused by these two AtomicInteger (and AtomicLong etc.) methods: because apparently they call exactly the same unsafe.compareAndSwapInt method.

I'm particularly confused in that AtomicInteger got introduced in Java 1.5, so after the Java Memory Model change (so it is obviously not something that could "fail spuriously in 1.4" but whose behavior changed to "shall not fail spuriously in 1.5").

解决方案

There is a difference between implementation and specification...

Whilst on a particular implementation there may not be much point in providing different implementations, future implementations perhaps on different hardware may want to. Whether this method carries its weight in the API is debatable.

Also the weak methods do not have happens-before ordering defined. The non-weak versions behave like volatile fields.

这篇关于如果weakCompareAndSet如果实现完全像compareAndSet，会如何失败？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！