How volatile guarantees visibility and instruction reordering

How volatile guarantees visibility

When each thread manipulates data, it reads the data from the main memory to its own working memory. According to the MESI idea, if a thread modifies the data and writes it back to the main memory, other threads can detect that the local data is invalid through sniffing, and then Reread from the main memory to its own working memory.

How volatile guarantees instruction reordering

Prevent instruction reordering by adding memory barriers between instructions.

 

basic concept

MONTHS

M odified (modified), E Xclusive (mutually exclusive), S Hare (shared), the I NVALID (invalid)

When CPU1 uses shared data, it will first copy the data to the CPU1 cache and then set it to the exclusive state (E). At this time, CPU2 also uses the shared data and copy it to the CPU2 cache and set it to the exclusive state (E). Through the bus sniffing mechanism, when the CPU1 monitors other CPUs in the bus to operate the memory, the state of the shared variable in the two caches of CPU1 and CPU2 will be marked as a shared state (S).

If CPU1 writes the variable back to the main memory through the cache, the cache line needs to be locked first. At this time, the state is switched to (M), and a message is sent to the bus to tell other CPUs that are sniffing that the variable has been changed by CPU1 and written back to Main memory. Other CPUs that receive the message will change the state of the shared variable from (S) to the invalid state (I), and the cache line is invalidated. If other CPUs need to operate shared variables again, they need to read them from memory again.

Sniff

Each processor checks whether its cache data has expired by sniffing the data spread on the bus. When the processor finds that the memory address corresponding to the cache data has been modified, it will set the current processor’s cache data to be invalid. State, when the processor modifies this data, it will read the data from the system memory to the processor cache again.

Bus storm

Use unsafe to implement CAS in Java, and its bottom layer is implemented by C++ calling assembly instructions. If it is a multi-core cpu, it uses the lock cmpxchg instruction, and a single-core cpu uses the compxch instruction.

If a large number of CAS operations are generated in a short period of time, coupled with the volatile sniffing mechanism, the bus bandwidth will be continuously occupied, leading to a surge in bus traffic, and a bus storm will occur.

happens-before

Since JDK 1.5, the concept of happens-before has been proposed. If the result of an operation needs to be visible to another operation, then there must be a happens-before relationship between the two operations.

 

important point

1. Volatile can only guarantee visibility, not atomicity. However, modifying long and double with volatile can guarantee the atomicity of its operation.

2. The read and write operations of volatile attributes are all lock-free.

 

Guess you like

Origin blog.csdn.net/Anenan/article/details/114955578