JMM and Happens-before

Happens-before is the core concept of JMM, understanding Happens-before is the key to understanding JMM.

I. Design of the JMM

First, let's analyze the design intent of JMM. From the perspective of JMM designers, there are two key factors to consider when designing a JMM:
1. Programmer's use of the memory model. Programmers want the memory model to be easy to understand and easy to program. Programmers want to write code based on a strong memory model.

2. Implementation of the memory model by the compiler and processor. The compiler and the processor want the memory model to be less bound to them, so they can do as much optimization as possible to improve performance. The compiler and the processor want to implement a weak memory model.

These two factors contradict each other, so the core goal of the JSR-133 Expert group in designing JMM is to find a good balance: on the one hand, to provide the programmer with sufficient memory visibility guarantees; On the other hand, limit the compiler and processor to be as relaxed as possible. Let's look at how JSR-133 is achieving this goal.

Double pi = 3.14;　　　　 Adouble R = 1.0;　 bdouble area = Pi * R * r; C

In the code above to calculate the area of a circle, there are three happens-before relationships:
A Happens-before B

B Happens-before C

A Happens-before C

In the three Happens-before relationships 2 and 3 are necessary, and 1 are unnecessary. So JMM divided the following two categories of happens-before required to ban the reordering

1. Reordering of program execution results

2. Reordering of program execution results will not change

JMM's reordering of these two different properties uses a different strategy, as follows:
1. For reordering of program execution results, JMM requires the compiler and processor to disallow such reordering

2. JMM does not require the compiler and processor to reorder the results of the program execution (JMM allows this reordering)

It's JMM's design.

　　

JMM provides programmers with happens-before rules that meet programmers ' requirements, JMM's happens-before rules are easy to understand and provide programmers with sufficient memory visibility guarantees.

JMM has had as few constraints on compilers and processors as possible. As can be seen from the above analysis, JMM is actually following a basic principle: as long as the execution results of the program are not changed (that is, single-threaded and correctly synchronized multithreaded programs), the compiler and the processor how to optimize the line. For example, if the compiler undergoes a careful analysis and determines that a lock will only be accessed by a single thread, the lock can be eliminated. If, after careful analysis, the compiler determines that a volatile variable will only be accessed by a single thread, the compiler can treat the volatile variable as a common variable. These optimizations will not change the execution result of the program, but also can improve the execution efficiency of the program.

Two. Definition of Happens-before

The concept of Happens-before was originally proposed by Leslie Lamport in one of its far-reaching papers ("Time,clocks andthe ordering of Events in a distributed System"). Leslie Lamport uses Happens-before to define partial-order relationships (partial ordering) between events in a distributed system. Leslie Lamport In this paper, we give a distributed algorithm, which can extend the partial order relation to some kind of whole order relation.

JSR-133 uses the concept of Happens-before to specify the order of execution between two operations. Both operations can be within a thread or between different threads. As a result, JMM can provide the programmer with a happens-before relationship with a cross-thread memory visibility guarantee (if there is a happensbefore relationship between the write operation A and the B thread's read operation B in the a thread, although the A and B operations are performed in different threads, But JMM assures the programmer that a operation will be visible to the B operation.

"Jsr-133:java Memory Model and Thread specification" defines the Happens-before relationship as follows:

1. If one operation Happens-before another operation, the result of the first operation will be visible to the second operation, and the order of execution of the first operation is preceded by the second operation.

2. The existence of a happens-before relationship between the two operations does not imply that the specific implementation of the Java platform must be performed in the order specified by the Happens-before relationship. This reordering is not illegal if the execution results after reordering are consistent with the results performed by the happens-before relationship.

The above 1 is JMM's commitment to programmers. From the programmer's point of view, the happens-before relationship can be understood this way: if a happens-before B, then the Java memory model will assure the programmer that the results of the--a operation will be visible to B, and that A's order of execution precedes B. Note that this is just a guarantee from the Java memory model to the programmer!

The above 2 is the JMM constraint on the compiler and processor punch ordering. MM is in fact following a basic principle: as long as the implementation of the program does not change the results, compiler and processor how to optimize the line. The purpose of this happens-before is to improve the degree of parallelism of the execution of the program as much as possible without changing the results of the program execution.

Three. Happens-before rules

1. Program sequence rules: Each action in a thread, happens-before any subsequent action in that thread

2. Monitor lock rule: Unlock a lock, happens-before to lock the lock later

3.volatile variable rule: Writes to a volatile field, happens-before to any subsequent reading of this volatile field

4. Transitivity: If a happens-before B, and B happens-before C, then a happens-before c

5.start rule: If thread A performs an operation Threadb.start () (boot thread B), then the Threadb.start () operation of the A thread happens-before any action in thread B

6.join rule: If thread A performs an operation Threadb.join () and returns successfully, any action in thread B happens-before the successful return of thread A from the Threadb.join () operation.

JMM and Happens-before