Reentrant Lock & Spin Lock & Atomicreference and CAS operations in Java & non-reentrant Linux mutexes

I've written quite a few articles about locks before:

Http://www.cnblogs.com/charlesblc/p/5994162.html "reprint" the lock mechanism in Java synchronized & bias Lock & Lightweight Lock & Heavyweight Lock & respective

Http://www.cnblogs.com/charlesblc/p/5935326.html "[Todo] Optimistic pessimistic lock, spin mutex, etc."

http://www.cnblogs.com/charlesblc/p/6146917.html "reprint" simultaneous and mutually exclusive POSIX support (mutex, condition variable, spin lock)

Http://www.cnblogs.com/charlesblc/p/6134658.html "Todo" Second kill system & optimistic Lock & Nginx reverse Proxy

Http://www.cnblogs.com/charlesblc/p/5996255.html "Todo" "reprint" the lock mechanism in Java 2-lock

Write one more, and deepen your understanding.

In the learning of Java memory model, see Reentrantlock Description, a little remember, looked up the information.

Refer to this article below: http://www.jb51.net/article/57338.htm

Lock as a tool for concurrent shared data, ensuring consistency, there are many implementations in the Java platform (such as synchronized and Reentrantlock, etc.). These locks have been written to provide convenience for our development, but the specific nature and type of the lock are rarely mentioned. This series of articles will analyze common lock names and features in Java to help you answer questions.

Can be re-entered lock:

This article is about a generalized reentrant lock, rather than a single-Reentrantlock under Java.

A reentrant lock, also called a recursive lock , means that the inner recursive function still has the code to acquire the lock after the same thread's outer function acquires the lock, but is unaffected.
Both Reentrantlock and synchronized are reentrant locks in the Java environment.

Usage examples:

 Public classTestImplementsrunnable{ Public synchronized voidget () {System.out.println (Thread.CurrentThread (). GetId ()); Set (); }  Public synchronized voidset () {System.out.println (Thread.CurrentThread (). GetId ());} @Override Public voidrun () {get ();} Public Static voidMain (string[] args) {Test ss=NewTest (); NewThread (ss). Start (); NewThread (ss). Start (); NewThread (ss). Start ();}}

As a result, it is correct that the same thread ID is continuously output two times.

Threadid:889 9

The maximum effect of reentrant locks is to avoid deadlocks.
We use spin locks as an example. ( Note: Spin lock, is not to get the lock will not stop the rotation cycle detection to wait , not into the kernel state of sleep, but in the user-state spin attempt)

 Public classSpinLock {Private atomicreference<Thread> owner =NewAtomicreference<>();  Public voidLock () {Thread current=Thread.CurrentThread ();  while(!owner.compareandset (NULL, current)) {  } }
 Public voidunlock () {Thread current=Thread.CurrentThread (); Owner.compareandset (Current,NULL); }}

Above is an implementation of a spin lock.

For spin locks:

1, if there is the same thread two call lock (), will cause the second call to the lock position spin, resulting in deadlock
Indicates that the lock is not reentrant . (Within the lock function, you should verify that the thread is the thread that has acquired the lock)
2, if the 1 problem has been resolved, when unlock () First Call, the lock has been released. You should not actually release the lock.
(statistics are used in counting times)

After the modification, the following:

 Public classSpinLock1 {Private atomicreference<thread> owner=NewAtomicreference<>(); Private intCount =0;  Public voidLock () {Thread current=Thread.CurrentThread (); if(current==Owner.get ()) {Count++; return ; }   while(!owner.compareandset (NULL, current)) {  } }
 Public voidunlock () {Thread current=Thread.CurrentThread (); if(current==Owner.get ()) {   if(count!=0) {Count--; }Else{Owner.compareandset (current,NULL); }  } }}

The spin lock implemented in this way is a reentrant lock.

Also, look at the situation of the mutex:

Mutexes can be divided into recursive locks (recursive mutexes) and non-recursive locks (non-recursive mutexes). A recursive lock can also be called a reentrant lock (reentrant mutex),
Non-recursive locks are also called non-reentrant locks (non-reentrant mutexes).

The only difference is that the same thread can get the same recursive lock multiple times, without creating a deadlock. If a thread acquires the same non-recursive lock multiple times, a deadlock occurs.

Mutexes and critical sections under Windows are recursive.

pthread_mutex_t locks under Linux are non-recursive by default. You can display the settings Pthread_mutex_recursive property and set pthread_mutex_t as a recursive lock.

Finish

Reentrant Lock & Spin Lock & Atomicreference and CAS operations in Java & non-reentrant Linux mutexes