CPU instructions executed out of order problem

1. problem out of order

In order to improve the efficiency of CPU instruction execution, during the execution of an instruction will be (such as read data to the memory (100 times slower)), to simultaneously execute another instruction, with the proviso that no two instructions dependencies

https://www.cnblogs.com/liushaodong/p/4777308.html

Write operations can also be combined

https://www.cnblogs.com/liushaodong/p/4777308.html

2. How to ensure that a particular case is not out of order

X86 hardware memory barrier

sfence: store | when the write operation must be completed before the sfence instruction writes before sfence instructions. lfence: load | must be completed before the read operation after lfence instruction in reading instruction before the operation when lfence. mfence: modify / mix | when read and write operations must complete before the read and write operations MFENCE instruction before MFENCE instruction.

Atomic instructions, such as "lock ..." on the x86 instruction is a Full Barrier, will lock when performing memory subsystem to ensure the implementation of the order, even across multiple CPU. Software Locks usually atoms or a memory barrier instructions to implement procedures to maintain visibility and variable sequence

How JVM-level specification (JSR133)

LoadLoad barrier: For such statements Load1; LoadLoad; Load2,

Before Load2 and subsequent data read operations to be read is accessed, the data Load1 guaranteed to be read is read is completed.

StoreStore barrier:

For such statements Store1; StoreStore; Store2,

Before the write operation is performed and subsequent Store2 ensure Store1 write operation visible to other processors.

LoadStore barrier:

For such statements Load1; LoadStore; Store2,

Before and subsequent write operation is Store2 brush, to ensure that the data to be read is read Load1 completed.

StoreLoad barrier: For such statements Store1; StoreLoad; Load2,

Before Load2 and all subsequent read operations performed to ensure Store1 writing visible to all processors.

volatile implementation details

1. Bytecode level ACC_VOLATILE

2. JVM-level volatile read-write memory area are added barrier

   StoreStoreBarrier

   volatile write operation

   Large Load Barrier

   LoadLoadBarrier

   volatile reads

   LoadStoreBarrier

3. OS and hardware level  https://blog.csdn.net/qq_26222859/article/details/52235930  hsdis - HotSpot Dis Assembler Windows Lock command to achieve

synchronized implementation details

1. Bytecode level ACC_SYNCHRONIZED monitorenter monitorexit
2. JVM level C C ++ calls a synchronization mechanism provided by the operating system
3. OS and hardware level X86: Lock cmpxchg / xxx  https://blog.csdn.net/21aspnet/article/details/88571740