[To] a summary of various mutual exclusion amounts

At the graduate level, C + + was used until the time of work to reach Java. Wrote so many years of multi-threaded program, feel for mutual exclusion (note, not synchronous OH) the various locks are necessary to do a summary.

Here I would like to use the Windows,linux and Java JVM in three environments with lock environment and although it is inappropriate to compare Windows,linux with Java JVM, but for Windows operating system c++,linux based on C + + and Java programs, at the application level, this horizontal comparison is meaningful for deepening the understanding of lock applications in multi-threaded mutexes. If there is an incorrect place, please correct me.

Windows

There are interlock series functions, critical_section critical section, Srwlock read-write lock, mutex mutex

Linux

With Atomic_t,mutex mutex, Rwlock read-write lock

Java JVM

Atomic atomic operation, synchronized sync keyword, reentrantlock,reentrantreadwritelock read-write lock

Mutex Amount	Environment	Sleep lock/Spin lock	Can be re-entered/non-reentrant	User state/Kernel state	can be interrupted/not interrupted	Note
Critical_section Critical Zone	Windows	First spin lock, rear sleep lock	Can be re-entered	User state
SRWLock Read/write lock	Windows	Read/write Lock	Do not re-enter	User state
Mutex Mutex amount	Windows	Sleep Lock	Do not re-enter	Kernel State
Spin_lock	Linux	Spin lock		Kernel
Mutex Mutex amount	Linux	Sleep Lock		Pthread
Rwlock	Linux	Read/write Lock		Pthread
Synchronized	Jvm	Class Spin Lock	Can be re-entered	JVM Internal Lock
Reentrantlock	Jvm	Class Sleep Lock	Can be re-entered	Locks for Java class libraries
Reentrantreadwritelock	Jvm	Read/write Lock	Can be re-entered	Locks for Java class libraries

Here's how to use a spin lock, when to use a read-write lock, and when to use a sleep lock.

Spin locks are best used when the critical area is small and the competition is not strong, and it is not possible to use a spin lock when it is not read and write to the file. This is because the spin lock is a "busy" way to preempt the lock, if the critical area range is large, or the competition is strong, or a kernel state operation, causing multiple threads to The CPU usage of the server will be very high, the context switch will be more frequent, the performance is poor. For the critical section of Windows, Microsoft has specifically optimized it to spin for a period of time, and then, if it doesn't enter the critical section for a long time, it uses a mutex to go to sleep.

When the number of read and write is very large, (read or write less or read less), use read-write lock, read-write lock, most of the time is a variant of the spin lock.

A sleep lock is best used when the critical zone is large or the critical section has kernel state operations, and the sleep lock enters the kernel state in case the lock is not preempted, so that the thread on which it is located is suspended. When the critical section is small, the length of time to enter the kernel state is likely to be greater than the length of time in the critical section, resulting in poor performance, but if the critical section is large, where the length of operation is greater than the length of time the sleep lock enters the kernel state, especially in highly competitive situations, the performance is better than the spin lock.

For the JVM, why do I write class spin locks and class sleep locks, because their performance is not the same as in C + +, In Java5.0, the performance of synchronized and the performance of Reentrantlock are similar to the performance of spin lock and sleep lock, but in Java6.0, the performance of synchronized in the race state has been greatly improved, so that in the case of race, Synchroniz The performance of Ed is basically consistent with the performance of Reentrantlock.

Finally, and most importantly, the above statements are inaccurate, and the only accurate is to test the performance results in your own code.

[To] a summary of various mutual exclusion amounts