[Go] Java CAS

Reference Links:

http://blog.csdn.net/liu88010988/article/details/50799978

The Java.util.concurrent package is built entirely on CAS, and there is no CAs to have this package. The importance of CAs is visible.

Cas

Cas:compare and swap, translated into comparison and exchanged.

In the Java.util.concurrent package, a kind of optimistic lock is distinguished from the Synchronouse synchronous lock by using CAs.

CAS applications

CAS has 3 operands, a memory value of V, an old expected value of a, and a new value to be modified B. If and only if the expected value A and the memory value of the V phase, the memory value of V is modified to B, otherwise do nothing.

Modern CPUs provide special instructions to automatically update shared data and detect interference from other threads, and Compareandset () replaces the lock with these.

Take out Atomicinteger to study how the data is correct without a lock.

private volatile int value;

In the first place, there is no doubt that the volatile primitives may be needed to ensure that data between threads is visible (shared) without a lock mechanism.

This allows the value of the variable to be read directly when it is obtained.

Public final int get () {
return value;
}

Then let's see how ++i did it.

Public final int Incrementandget () {
for (;;) {
int current = get ();
int next = current + 1;
if (Compareandset (current, next))
return next;
}
}

The CAS operation is used here, each time the data is read from memory and then the CAS operation is performed with the result of +1, if successful, the result is returned, otherwise it is retried until it succeeds.

Instead, Compareandset uses JNI to perform the operation of the CPU instructions.

Public final Boolean compareandset (int expect, int update) {
Return Unsafe.compareandswapint (this, valueoffset, expect, update);
}

The whole process is like this, using the CPU's CAS instruction, and using JNI to complete the Java non-blocking algorithm. Other atomic operations are done using a similar feature.

which

Unsafe.compareandswapint (this, valueoffset, expect, update);

Similar:

if (this = = expect) {

this = Update

return true;

} else {

return false;

}

CAs cons

CAS is an efficient solution to atomic operations, but CAS still has three major problems. ABA problem, long cycle time overhead and guaranteed atomic operation of only one shared variable

1. ABA issues. Because CAs needs to check that the value is not changed when the value is manipulated, if it does not change, it is updated, but if a value is a, B, and a, then checking with CAS will show that its value has not changed, but actually it has changed. The solution to the ABA problem is to use the version number. Append the version number before the variable, and add one to the version number each time the variable is updated, then A-b-a will become 1a-2b-3a.

A class atomicstampedreference is provided in the atomic package of the JDK starting with Java1.5 to solve the ABA problem. The Compareandset method of this class is to first check whether the current reference is equal to the expected reference, and whether the current flag is equal to the expected flag, and if all is equal, then atomically sets the reference and the value of the flag to the given update value.

About ABA Issues Reference document: Http://blog.hesey.net/2011/09/resolve-aba-by-atomicstampedreference.html

2. Long cycle time overhead. Spin CAs can cause very large execution overhead for CPUs if they are unsuccessful for a long time. If the JVM can support the pause instruction provided by the processor then the efficiency will be improved, the pause command has two functions, first it can delay the pipelining instruction (de-pipeline), so that the CPU does not consume excessive execution resources, the delay depends on the specific implementation of the version, On some processors, the delay time is zero. Second, it avoids the CPU pipelining being emptied (CPU pipeline flush) when exiting the loop due to memory order collisions (violation), which improves CPU execution efficiency.

3. Only one atomic operation of a shared variable can be guaranteed. When performing operations on a shared variable, we can use the method of circular CAs to guarantee atomic operations, but for multiple shared variables, the cyclic CAS cannot guarantee the atomicity of the operation, it is possible to use locks at this time, or there is a trickery way to combine multiple shared variables into a single shared variable to operate. For example, there are two shared variable i=2,j=a, merge ij=2a, and then use CAs to manipulate IJ. Starting with Java1.5 The JDK provides the Atomicreference class to guarantee atomicity between reference objects, and you can put multiple variables in an object for CAS operations.

Implementation of concurrent Package

Because Java's CAs have both volatile read and volatile write memory semantics, communication between Java threads now has the following four ways:

1. A thread writes the volatile variable, and then the B thread reads the volatile variable.
2. A thread writes the volatile variable, and then the B thread updates the volatile variable with CAs.
3. A thread updates a volatile variable with CAS, and then the B thread updates the volatile variable with CAs.
4. A thread updates a volatile variable with CAS, and then the B thread reads the volatile variable.

The CAs in Java use the high-efficiency machine-level atomic instructions available on modern processors that atomically perform read-and-write operations on memory, which is the key to achieving synchronization in a multiprocessor (essentially, a computer that supports atomic read-change-write instructions, is an asynchronous equivalent machine for calculating Turing machines sequentially, so any modern multiprocessor will support some atomic instruction that performs atomic read-and-write operations on memory. At the same time, the read/write and CAS of volatile variables can implement communication between threads. The integration of these features forms the cornerstone of the entire concurrent package. If we carefully analyze the source code implementation of the concurrent package, we will find a generalized implementation pattern:

1. First, declare the shared variable to be volatile;
2. Then, the synchronization between threads is realized by using the atomic condition update of CAs.
3. At the same time, the communication between threads is implemented with volatile read/write and the volatile reading and writing memory semantics of CAs.

AQS Abstractqueuedsynchronizer, Non-blocking data structures and atomic variable classes (classes in the Java.util.concurrent.atomic package), the underlying classes in these concurrent packages, are implemented using this pattern, and the high-level classes in the concurrent package are dependent on these base classes for implementation. Overall, the concurrent package is implemented as follows:

[Go] Java CAS