Java memory model-memory semantics of locks

An introduction

When it comes to volatile memory semantics, there is a saying: There is a good way to understand the volatile nature of a volatile variable, which is to use a single read/write for variables that is synchronized with the same lock for these individual read/write operations. So actually the release and acquisition of the lock has the same memory semantics as the volatile write and read.

Release of two locks-acquisition of established Happens-before relations

If you don't know the rules of Happens-before, please go and see--look, this is not the case. Since there is no previous example of a monitor lock rule, here is a detailed description, following the lock release-get Sample code:

 Public classMonitorexample {intA = 0;  Public synchronized voidWriter () {//1A + = 1;//2}//3     Public synchronized voidReader () {//4System.out.println (a);//5}//6     Public Static voidMain (string[] args) {FinalMonitorexample me =Newmonitorexample (); Thread T1=NewThread (NewRunnable () {@Override Public voidrun () {me.writer ();        }        });        T1.start (); Thread T2=NewThread (NewRunnable () {@Override Public voidrun () {me.reader ();        }        });    T2.start (); }}

Here we assume that thread 1 executes the writer () method first, and then thread B executes the reader () method (knowing why?). Because it is not necessarily in this order, you can test the results . According to Happens-before rules, this process contains a happens-before relationship that can be divided into 3 categories:

1) According to the Rules of Procedure order: 1 Happens-before 2, 2 Happens-before 3, 4 Happens-before 5, 5 Happens-before 6;

2) According to the Monitor lock rule: 3 Happens-before 4;

3) According to the transitive rules, 2 happens-before 5.

The graphical representation of the above Happens-before relationship is as follows:

Memory semantics for the release and acquisition of three locks

When a thread releases a lock, JMM flushes the shared variable in the local memory corresponding to that thread into main memory. As an example of the above Monitorexample program, after thread 1 releases the lock, the state of the shared data is as follows:

When a thread acquires a lock, JMM will place the local memory corresponding to that thread as invalid. This allows the critical section code protected by the monitor to read shared variables from main memory.

Comparing lock Release-read memory semantics with volatile write-read memory semantics, the lock release has the same memory semantics as volatile writes; lock fetching has the same memory semantics as volatile reads. A summary of the memory semantics for lock release and lock acquisition.

• Thread 1 frees a lock, essentially thread 1 sends a message (thread 1 changes to a shared variable) to a thread that is going to acquire the lock.
• Thread 2 acquires a lock, which is essentially thread 2 receiving a message from a previous thread (modified to a shared variable before releasing the lock).
• Thread 1 locks are released, and then thread 2 acquires the lock, which is essentially a process in which thread A sends a message to thread B through main memory.

implementation of four lock memory semantics

There are many kinds of locks, but the basic principles are similar. The book is to Reentrantlock in the fair lock and unfair lock as a case analysis, interested students can read the origin and source. It is summarized as follows:

• When a fair lock and an unfair lock are released, the last one is to write a volatile variable state.
• Fair lock Fetch Yes, first read the volatile variable.
• When a non-fair lock is acquired, the volatile variable is first updated with CAs, which has the memory semantics of both volatile read and write.

So lock release-gets the implementation of memory semantics at least in the following two ways:

　　1) Use the memory semantics of the write-read of the volatile variable.

2) Use the memory semantics of the volatile read and volatile writes that are included with CAs.

The following: The implementation of classes under concurrent packages is mostly implemented in these two ways.

Java memory model-memory semantics of locks