Happen-before Principles

thinking in the course of learning

Recently learning concurrency knowledge, see a very classic code, as follows:

count = 1; thread 1{  operation 1:count++;} Thread 2{  operation 2:count++;}

In a concurrent environment, thread 1 and thread 2 perform their own operations at the same time, then the result of the operation must be 3? We know that count++ is not an atomic operation, and count++ the operation into three processes when the computer executes the instruction, 1. Value the intermediate variable, 2. The value of the intermediate variable +1,3. Then assign to the original variable. Therefore, in a concurrency environment, the results are very uncertain. This means that the result of operation 1 is not necessarily visible to Operation 2.

Take another look at code 2:

int a = b = 0, thread 1{operation 1:a = 1; Operation 2:b = 2;} Thread 2{if (b==2)  System.out.println (a); What is the value of//a? }

In a concurrent environment, thread 1 and thread 2 run simultaneously, how much does the thread print? Must be 1? Because the compiler has reordering optimizations, operations 1 and 2 may be exchanged sequentially in the compiler. So when thread 1 runs to Operation 2, maybe a has not been assigned, which means that thread 2 output a results in 0;

Think: In a multi-threaded environment, in what case, the result of the previous operation will be visible to the result of the latter operation? In the case of single-threaded sequential execution, will the optimization of code reordering occur? What can I do to ensure the visibility of results when I'm developing? Through a series of studies, the original above my doubts, there is a like 9*9 multiplication tables similar to the formula, with this formula, we can in the concurrency situation, write a sound program.

Haha, then what is this formula? Yes, it is the happen-before principle, I like to say it as Happen-before formula.

What is the Happen-before principle? Happens-before: If there is a happens-before relationship between the two operations, the result of the previous operation will be visible to the subsequent operation. Common Happens-before Rules:1. Program Order rules: Each action in a thread is happens-before to any subsequent action in that thread.
(Note: If there is only one thread of action, the result of the previous operation will certainly be visible to subsequent operations.) )2. Monitor Lock rule: Unlocks a monitor lock, happens-before to the locking of the subsequent lock on the monitor.
( Note: The most common is the Syncronized method and the syncronized block) 3. Volatile variable rule: write to a volatile field, happens-before to any subsequent reading of this volatile field.

int a = 0; volatile int b = 0; thread 1{operation 1:a = 1;//Insert a storestore barrier prohibit above normal write with the following volatile write-reorder operation 2:b = 2;} Thread 2{if (b==2)//loadload barrier. Prohibit the above volatile with the following general reading order  System.out.println (a); What is the value of//a? }

Because there is a barrier, the JVM does not reorder the above code.
4. transitivity: If a happens-before B, and B happens-before C, then a Happens-before c. (note: This looks like a single-threaded sequential execution ... )
Extended JVM Memory Barrier insertion strategy: Insert a storestore barrier before each volatile write operation.
Insert a storeload barrier behind each volatile write operation.
Insert a loadload barrier behind each volatile read operation.
Insert a loadstore barrier behind each volatile read operation.
The memory barrier insertion strategy described above is very conservative, but it guarantees correct volatile memory semantics on any processor platform and in any program.

we believe that with these rules, we can develop better concurrency programs only by understanding them.

Happen-before Principles