Study notes (37): Chapter 1 Distributed Foundation of Concurrent Programming-Explore the essence of volatile 02 behind thread safety

Learn now: https://edu.csdn.net/course/play/29000/405251?utm_source=blogtoedu

1. How can optimization failure at the CPU level solve the visibility problem and instruction reordering problem?

That is to invalidate the cache in real time, and read data from the memory = "That is to make a memory barrier

The function of the memory barrier is to not allow instruction reordering and disable the cache

Adding the volatile keyword will increase this memory barrier

2. Java Memory Model (JMM) defines the specification of multi-threaded read and write in shared memory, solves the differentiation of different platforms, provides a uniform thread safety consistency model, and provides visibility and orderliness. s solution

3. The developed instructions to the executed instructions will be optimized in three steps

Source code = "Compiler optimization reordering = "(CPU level) Instruction level parallel reordering = "(CPU level) Memory system reordering = "Final execution ordering

These optimizations will cause visibility problems, so the hardware level provides a memory barrier to solve this problem, and the software level provides a method to call the memory barrier.

4. In summary, how does volatile solve the visibility problem?

Provides a mechanism to prevent reordering of memory instructions and solves the visibility problem through a memory barrier mechanism

5. So when is volatile used?

There is the possibility of multiple thread access and concurrent access, so volatile is needed to ensure visibility

6. The double check lock judgment instance==null in the singleton mode of the extended problem

A a;

a=new A();

new A() In the operating system, three instructions will have reordering problems, so you need to add the volatile keyword

static volatile A a;

a=new A();

7. Happens-Before model-a model that solves the visibility problem by itself at the software level

A Happens Before B, it is not that A must run before B, but the result value of A is visible to B

Under what circumstances will this model exist?

(1) Procedure sequence rules (as-if-serial)

Cannot change the execution result of the program (in a single-threaded environment, the execution result remains unchanged)

Dependency problem, if two instructions have a dependency relationship, reordering is not allowed

int a=0;int b=1; int c=a*b;

(2) Transitive rules

A Happens Before B;

B Happens Before C;

The result of A must be visible to C

(3) Volatile variable rules

The write operation of volatile modified variable must be hanppens-before subsequent read operation of vaolatile variable, because the memory barrier mechanism prevents instruction reordering

(4) Monitor lock rules

 The release operation of a lock must be hanppens-before. The subsequent operations of other threads corresponding to the lock are actually synchronized(); it is locked by itself, so it is visible in all threads and cannot be reordered.

(5) Start rule

int x=10;

Thread t1=new Thread(()->{read x value, it must be 20}); 

x=20;

t1.start();

The operation before start must be any operation in the hapens-before thread

(6) Join rules

Thread.join(); is a blocking behavior

 

Guess you like

Origin blog.csdn.net/qq_28500837/article/details/112978549