Talk about high concurrency (36) Java memory Model those things (iv) Understanding Happens-before rules

In the previous few things about the Java memory model that basically explained the concept of the bottom of the domain, talk about high concurrency (35) Java memory model those things (iii) Understanding memory barriers This analysis of the X86 platform, Volatile,synchronized, CAS operations are implemented based on the assembly instructions of the lock prefix, and there are two key points about the lock directive:

1. Lock locks the bus, the bus is mutually exclusive, so the write operation behind lock is written to the cache and memory, which can be understood as the two actions of write cache and write memory behind lock are called an atomic operation. When the bus is locked, the other CPU is unable to use the bus, but also let other read and write are waiting for the release of lock

2. After the lock is written, the cache and memory of the CPU that originated it is up-to-date, the other CPU-related cache lines are invalidate, and subsequent read/write caches are not hit, reloading the latest values from memory.

Here is an implied point, I did not find specific information, but according to a lot of information: volatile write operation equivalent to release the lock, volatile read operation equivalent to enter the lock can make the following inference:

The volatile operation is a variable, and the lock-protected program segment involves variables that can be multiple, since the effect of the two is the same, then it is likely that the lock behind the write will let the cache/write buffer all the dirty data are flushed back to main memory. Only in this way can the visibility of volatile in terms of visibility and lock-protected program segments be consistent in behavior.

It is important to understand this because it is related to the Happens-before transitive nature of this speech. Happens-before just saw from the language is difficult to understand, think is nonsense, but it actually describes the problem is the visibility of the problem, along with some because of the order to prevent reordering problems . Talk about high concurrency (33) Java memory Model Those things (i) Understanding Java memory Model from the perspective of consistency (consistency) This said that the memory model is the consistency of the problem domain, the consistency problem only involves the visibility and order of the two characteristics, does not contain atomicity, So Happens-before is actually a series of consistency constraints, so it involves the meaning of visibility and order, but not the meaning of atomicity.

Happens-before Vulgar Solution This article has been written very clearly, my side and then combined with a memory barrier of some concepts icing on the cake, further explain the problem

The following happens-before rules are extracted from the JSR 133 (Java Memory Model) FAQ

• Each of the action in a thread happens before every action in this thread that comes later in the program ' s order.
• It can be understood that for a single thread, the previous write operation is visible to the back, and there must be someone asking how to guarantee this after the order reordering, and I have this question, so I understand that if this write is synchronous, then the single thread says that all synchronous writes are in accordance with program order, This is also the first meaning of sequential consistency. To understand that, after using the synchronization method, the synchronized protection points are guaranteed to be consistent in order. Because the underlying implementation of synchronization, such as memory barrier/lock, has the meaning of preventing reordering
  

• An unlock in a monitor happens before every subsequent lock on that same monitor.
• Can be understood as a lock after the release of its previous write operation on the subsequent access to the same lock thread visible, for the lock is too sure, the release will lock Cmpxchg once, enter will lock CMPXCHG once, both guaranteed visibility

• A write to a volatile field happens before every subsequent read about that same volatile.
• The write operation that can be understood as volatile is visible to subsequent reads, and the lock ADDL operation guarantees the visibility of write volatile

• A call to start () on a thread happens before any of the actions in the started thread.
• It can be understood that thread start () writes the state of the thread to the other actions of subsequent threads, the JVM is processed internally, and the actual implementation is definitely implemented using the lock/memory barrier, actually talking about the JVM (ix) Understanding how to get all Java threads blocked when entering SafePoint we refer to the change in thread state, in the JVM is a thread state variable atomic modification, this state change is atomic, and visible, of course, has the ability of Happens-before
  

• All the actions in a thread happen before any and thread successfully returns from ajoin () on that thread.
• It can be understood that all writes in a join thread are visible to the original thread when it returns to the original thread after its join has ended. This is similar to the above principle, that is, the JVM when modifying the state of the thread is an atomic operation, and ensure the visibility (estimated to be a CAs), so even with the modified state before the changes are also visible to the subsequent operation

Other Happens-before rules, such as CAS operations, change of atomic variables have happens-before meaning, and happens-before have transitivity, such as A happens Beofre B, b happens Before C, then a definitely happens before c.

Why has transitivity, the reason is still at the beginning of the time said, lock/memory barrier not only the current address of the data atom writes to the cache and memory, it must also be the CPU cache/write buffer of dirty data written back to the main memory, so that the implementation of happens The transitivity of the before.

So all the places that use volatile, synchronized, CAs have happens before, both explicit and atomic variables are based on CAs, and of course they have happens before transitivity when used.

So the following example is well understood, such as y is a volatile variable or an atomic variable/Synchronizer class and so on to the CAS

Thread A thread B

x = 1 A = y

y = 2 B = x

If, in chronological order, the y=2 of this pair of synchronized variables occurs first, the read of the variable that is synchronized to a = y, then you can say b = x = 1 for sure.

Someone asked if x = 1 would not be re-queued to Y = 2, the answer is no, because Y is a synchronized variable, prevents reordering, X does not cross the memory barrier after the y=2, so

b = x is also not reordered to the front of a = y, because y is a variable that is synchronized, and the memory barrier also does not allow the actions behind the barrier to cross over to the front

So as long as Y =2 writes occur before a = y read operation, then the last x = 1 must precede b=x, so B = 1

Resources:

Happens-before of the Vulgar solution

Talk about high concurrency (36) Java memory Model those things (iv) Understanding Happens-before rules