Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are Happens-Before principles and As-If-Serial semantics". In daily operation, I believe many people have doubts about Happens-Before principles and As-If-Serial semantics. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "what are Happens-Before principles and As-If-Serial semantics?" Next, please follow the editor to study!

JMM memory model

Java memory model is a concurrent model of shared memory. Threads communicate implicitly by reading-writing shared variables.

The shared variables in Java are stored in memory, and multiple threads work in their working memory. The working way is to take out the variables in the shared memory and put them in the working memory. After the operation is completed, the latest variables are put back to the shared variables, and then other threads can get the latest shared variables.

From a horizontal point of view, thread An and thread B seem to be communicating implicitly by sharing variables. There is an interesting problem. If the updated data of thread An is not written back to main memory in time, and thread B reads the expired data, there will be a "dirty read" phenomenon.

To avoid dirty reading, it can be solved through the synchronization mechanism (controlling the relative order of operations between different threads) or through the volatile keyword so that each volatile variable can be forced to flush to the main memory, so that it is visible to each thread.

Reorder

When executing a program, compilers and processors often reorder instructions in order to improve performance. General reordering can be divided into three categories: as shown in figure 1. It belongs to compiler reordering, while 2 and 3 are collectively referred to as processor reordering.

These reordering can lead to thread safety problems, and a classic example is the DCL problem. JMM's compiler reordering rules prohibit certain types of compiler reordering; for processor reordering, the compiler forbids some special processor reordering by inserting memory barrier instructions when generating instruction sequences.

(1) Compiler optimized reordering: the compiler can rearrange the execution order of statements without changing the semantics of a single-threaded program.

(2) instruction-level parallel reordering: modern processors use instruction-level parallel technology to execute multiple instructions overlapping. If there is no data dependency, the processor can change the execution order of the statements corresponding to the machine instructions

(3) reordering of memory system. Because the processor uses caching and read / write buffers, it appears that load and storage operations may be performed out of order.

For example: public double rectangleArea (double length, double width) {double leng; double wid; leng=length;//A wid=width;//B double area=leng*wid;//C return area;}

Since there is no relationship between AQuery B and the final result, the order of execution between them can be reordered. Therefore, the execution order can be A-> B-> C or B-> A-> C. the end result is 3.14, that is, there is no data dependency between An and B.

Because A happens-before B, the result of An operation leng must be visible to B operation, but now B operation does not use length, so these two operations can be reordered. Can An operation be reordered with C operation? if An operation and C operation are reordered, because leng is not assigned, leng=0,area=0*wid is area=0. This result is obviously wrong, so the An operation cannot be reordered with the C operation (that is, the execution result of the previous operation mentioned in note 2 must be visible to the Hou Yi operation. If this requirement is not met, reordering of these two operations is not allowed)

What is happens-before (JMM-oriented specification principles and compiler-level principles) under multithreading scenarios

JMM can provide cross-thread memory visibility through happens-before relationships (if there is an happens-before relationship between thread A's write operation an and thread B's read operation b, although an and b operations are performed in different threads, JMM assures the programmer that an operation will be visible to b operation).

Specific definition:

1) if one operation happens-before another operation, the execution result of the first operation will be visible to the second operation, and the execution order of the first operation comes before the second operation.

2) the existence of a happens-before relationship between the two operations does not mean that the specific implementation of the Java platform must be executed in the order specified by the happens-before relationship. If the execution result after the reorder is consistent with the result performed according to the happens-before relationship, then this reorder is not illegal (JMM allows such a reorder).

Specific rules:

(1) Program order rules: each operation in the thread, happens-before any subsequent operation of the thread.

(2) Monitor lock rule: unlock the lock, which is subsequently locked by happens-before.

(3) volatile variable rule: write to the volatile field, happens-before to any subsequent read / write to the Volume domain.

/ / A write operation of a volatile variable happen-before any operation on this variable: volatile int a _ X a = 1; / / 1b = a; / / 2Take / if thread 1 executes 1, "thread 2" executes 2, and "thread 1" executes, "thread 2" executes again, then conforms to the "volatile's / / happen-before principle", so the a value in "thread 2" must be 1.

(4) transitivity: if A happens-before B and B happens-before C, then A happens-before C.

(5) start () rule: if thread An executes the operation ThreadB.start () (starts thread B), then thread A's ThreadB.start () operation happens-before any operation in thread B.

(6) Join () rule: if thread An executes the operation ThreadB.join () and returns successfully, then any operation happens-before in thread B returns successfully from the * * ThreadB.join () * * operation on thread A.

(7) Program interrupt rule: the call to the thread interrupted () method detects the occurrence of the interrupt time before the code of the interrupted thread.

(8) object finalize rule: the initialization of an object (the end of constructor execution) precedes the beginning of the finalize () method in which it occurs.

Happens-before has delivery rules

There are three happens-before relationships using the program order rule (rule 1):

A happens-before B

B happens-before C

A happens-before C

The third relation here is inferred by transitivity. The third relation here is inferred by transitivity.

Volatile int var;int / 1var = 3; / 2c = var; / / 3c = b; / / 4

Suppose Thread 1 executes the code / / 1 / 2 and Thread 2 executes the code / / 3 / 4. If the order of execution is as follows:

/ / 1 / / 2 / / 3 / / 4 . Then the derivation is as follows (hd (a happen-before b) stands for an and b):

Because there are hd (/ / 1) and hd (/ / 3) (happen-before principle of single thread)

And hd (/ / 2) (volatile's happen-before principle)

So there is hd (/ / 1), and hd (/ / 1) (transitivity of happen-before principle) can be derived.

So the value of the variable c ends with 4 if the order of execution is as follows:

/ / 1 / / 3 / / 2ax / / 4 then the result of the last four is uncertain. The reason is that / / 3 / / 2 is directly in line with any of the above eight principles and cannot be inferred by transitivity.

A happens-before B, definition 1 requires that the execution result of An is visible to B, and the execution order of An operation is prior to B operation, but at the same time, using the second item in the definition, An and B operations have no data dependence on each other, and the execution order of the two operations will not affect the final result. Without changing the final result, the two operations of An and B are allowed to reorder. That is, the happens-before relationship does not represent the final order of execution.

Introduction of As-If-Serial semantics (processor-oriented semantic specification) in single-threaded scenarios

No matter how much you reorder (the compiler and processor to improve parallelism), the execution result of a single-threaded program cannot be changed. Compilers, runtime, and processors must all follow as-if-serial semantics.

In order to comply with as-if-serial semantics, compilers and processors do not reorder operations that have data dependencies because such reordering changes the execution result. However, if there are no data dependencies between operations, they may be reordered by the compiler and processor.

At this point, the study of "what are the Happens-Before principles and As-If-Serial semantics" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.