The introduction

We know that compilers and processors reorder code to improve parallelism and optimize program performance. For instruction reordering, see Instruction reordering and data dependencies. However, in order to improve the parallelism of program execution without changing the execution result, we need to understand the AS-if-serial rule and the happens-before rule.

The as – if – serial rules

The as-if-serial semantics mean that the execution result of a (single-threaded) program cannot be changed, no matter how much reordering is done (to improve parallelism by the compiler and processor). The compiler, runtime, and processor must comply with the AS-IF-Serial semantics. To comply with the as-if-serial semantics, the compiler and processor do not reorder operations that have data dependencies because such reordering changes the execution result. However, if there are no data dependencies between the operations, they may be reordered by the compiler and processor. Example code is as follows:

int a=1;
int b=2;
int c=a+b;
Copy the code

There is a data dependency relationship between A and C, and there is a data dependency relationship between B and C. Therefore, c cannot be reordered before A and B in the final instruction sequence. But there is no data dependency between A and B, and the compiler and processor can reorder the execution order between A and B.

Happens-before rule

1 definition

The JMM can provide programmers with A guarantee of memory visibility across threads through A happens-before relationship (if there is A happens-before relationship between thread A’s write operation A and thread B’s read operation B, even though A and B are executed in different threads, But JMM assures the programmer that operation A will be visible to operation B. The specific definition is:

  1. If one action happens-before the other, the execution result of the first action will be visible to the second action, and the execution order of the first action precedes the second action.
  2. The existence of a happens-before relationship between 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. The JMM allows reordering if the result of the reordering is the same as the result of the happens-before relationship.

2 Six Rules

  1. Procedure order rule: For every action in a thread, happens-before any subsequent action in that thread.
  2. Monitor lock rule: a lock is unlocked, happens-before a lock is subsequently locked.
  3. Volatile variable rule: Writes to a volatile field, happens-before any subsequent reads to that volatile field.
  4. The transitive rule: 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 () (starts ThreadB), then thread A’s threadb.start () operation happens before any operation in ThreadB.
  6. Join () rule: if thread A performs the operation threadb.join () and returns successfully, any operation in ThreadB happens-before thread A returns successfully from threadb.join ().

The difference between as-if-serial and happens-before rules

  1. The as-if-serial semantics guarantee that the execution result of a program in a single thread is not changed, and the happens-before relationship guarantee that the execution result of a properly synchronized multithreaded program is not changed.
  2. The as-IF-serial semantics create the illusion for programmers who write single-threaded programs that they are executed in sequence. The happens-before relationship creates an illusion for programmers who write properly synchronized multithreaded programs: properly synchronized multithreaded programs are executed in the order specified by happens-before.
  3. Both the as-if-serial semantics and happens-before are intended to increase the parallelism of program execution as much as possible without changing the results of program execution.

A little attention, won’t get lost