How can weakCompareAndSet fail spuriously if it is implemented exactly like compareAndSet?

java concurrency javadoc
SyntaxT3rr0r picture SyntaxT3rr0r · Mar 14, 2010 · Viewed 8.1k times · Source

(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").

Answer

Tom Hawtin - tackline picture Tom Hawtin - tackline · Mar 14, 2010

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.

Related questions

How to wait for all threads to finish, using ExecutorService?

I need to execute some amount of tasks 4 at a time, something like this: ExecutorService taskExecutor = Executors.newFixedThreadPool(4); while(...) { taskExecutor.execute(new MyTask()); } //...wait for completion somehow How can I get notified once all of them are complete? For now …

Read More
What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)?

I have a Map which is to be modified by several threads concurrently. There seem to be three different synchronized Map implementations in the Java API: Hashtable Collections.synchronizedMap(Map) ConcurrentHashMap From what I understand, Hashtable is an old implementation (…

Read More
When and how should I use a ThreadLocal variable?

When should I use a ThreadLocal variable? How is it used?

Read More