3

Does AtomicInteger provide any kind of fairness guarantee? like first-come-first-serve execution order of threads on it? The animated example at Victor Grazi's concurrent animated definitely does not show any such fairness. I've searched and haven't found anything conclusive.

Rohan Grover
  • 1,514
  • 2
  • 17
  • 23

3 Answers3

5

No, there is no such guarantee. If there was one, it would be spelled out in the documentation.

When you think about it, AtomicInteger is basically a thin wrapper around compare-and-swap (or similar). Guaranteeing first-come-first-served semantics would require synchronization between threads, which is costly, and contrary to the very idea of AtomicInteger.

The way things are is that if there are multiple threads wanting to, say, incrementAndGet() the same atomic integer concurrently, the order in which they finish the race is unspecified.

NPE
  • 486,780
  • 108
  • 951
  • 1,012
  • `.compareAndSet()` supports order guarantee ( via `unsafe.compareAndSwapInt()` ), so this answer isn't correct. It **is** spelled out in the JavaDoc of `.weakCompareAndSet()` which says to use the previous method if you want order guarantee. –  May 25 '12 at 15:49
  • 2
    @JarrodRoberson: *Ordering guarantee* refers to happens-before relations. This has absolutely nothing to do with *first-come-first-served* resolution of races. – NPE May 25 '12 at 15:52
3

Its worth nothing that its operation is very fast compared to anything else you are likely to do. This means you are highly unlikely to get contention so fairness is unlikely to be an issue.

If you call it 2 billion times (which you can do in seconds) it will over flow anyway. If this is a concern I would use AtomicLong.

gd1
  • 11,300
  • 7
  • 49
  • 88
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • In fact, the material I've read (including JCIP, iirc) says that AtomicInteger et al are best suited for when you have low to moderate contention. If you have very high contention, such that the CAS operations frequently fail, then you should start looking at synchronization; you'll be trading off some speed in the best/uncontested case, for less "useless" work in the CAS. – yshavit May 25 '12 at 16:06
  • 1
    @yshavit That is true, but my point is that you have to have a number of thread which are just incrementing the counter and very little else. IMHO, Any real program which has a high contention on a counter and does not do much else has a design issue. – Peter Lawrey May 25 '12 at 16:12
  • 1
    That's true -- I think the warning against high-contention CAS is more relevant for when you use the `AtomicFoo.compareAndSet` methods "raw", where the body of the loop is non-trivial (where adding 1 to a local variable is definitely considered trivial). – yshavit May 25 '12 at 18:28
1

If you look at the source you will get the correct answer, which is YES and NO about ordering guarantees. It depends on which method is being called. Some support ordering guarantees, some don't.

The following source shows that it supports both modes depending on which method is called. 

  138       /**
  139        * Atomically sets the value to the given updated value
  140        * if the current value {@code ==} the expected value.
  141        *
  142        * <p>May <a href="package-summary.html#Spurious">fail spuriously</a>
  143        * and does not provide ordering guarantees, so is only rarely an
  144        * appropriate alternative to {@code compareAndSet}.
  145        *
  146        * @param expect the expected value
  147        * @param update the new value
  148        * @return true if successful.
  149        */
  150       public final boolean weakCompareAndSet(int expect, int update) {
  151           return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
  152       }

When in doubt read the JavaDoc, and if still not clear read the source.

  • *Ordering guarantee* refers to happens-before relations. This has absolutely nothing to do with *first-come-first-served* resolution of races. – NPE May 25 '12 at 15:54