std::atomic<double> is supported in the sense that you can create one in your program and it will work under the rules of C++11. You can perform loads and stores with it and do compare-exchange and the like. The standard specifies that arithmetic operations (+, *, +=, &, etc.) are only provided for atomics of “integral … Read more
The atomic objects make use of Compare and Swap mechanism to make them atomic – i.e. it is possible to guarantee that the value was as specified and is now at the new value. The code you posted continually tries to set the current value to one more than it was before. Remember that another … Read more
Lockfree programming is about progress guarantees: From strongest to weakest, those are wait-free, lock-free, obstruction-free, and blocking. A guarantee is expensive and comes at a price. The more guarantees you want, the more you pay. Generally, a blocking algorithm or datastructure (with a mutex, say) has the greatest liberties, and thus is potentially the fastest. … Read more
A weak compare and swap could act as a full volatile variable, depending on the implementation of the JVM, sure. In fact, I wouldn’t be surprised if on certain architectures it is not possible to implement a weak CAS in a notably more performant way than the normal CAS. On these architectures, it may well … Read more
“general pseudo code” is not an actual code of CAS (compare and swap) implementation. Special hardware instructions are used to activate special atomic hardware in the CPU. For example, in x86 the LOCK CMPXCHG can be used (http://en.wikipedia.org/wiki/Compare-and-swap). In gcc, for example, there is __sync_val_compare_and_swap() builtin – which implements hardware-specific atomic CAS. There is description … Read more
Why are you loading the old flags value twice in your CAS loops? The first time is by flags.load(), and the second by the compare_exchange_weak(), which the standard specifies on CAS failure will load the previous value into the first argument, which in this case is flagsNow. According to http://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange, “Otherwise, loads the actual value … Read more
It seems like part what you’re really asking is: Why isn’t the lock prefix implicit for cmpxchg with a memory operand, like it is for xchg (since 386)? The simple answer (that others have given) is simply that Intel designed it this way. But this leads to the question: Why did Intel do that? Is … Read more
CAS is generally much faster than locking, but it does depend on the degree of contention. Because CAS may force a retry if the value changes between reading and comparing, a thread can theoretically get stuck in a busy-wait if the variable in question is being hit hard by many other threads (or if it … Read more