Spin lock and mutex lock

Spin locks and mutex are two important concepts in concurrent programming. They are mainly used to lock shared resources to prevent Concurrent Data Access and ensure data consistency. But they also have some differences. This article mainly introduces these differences and describes when to use the spin lock and when to use the mutex lock.

Theoretical Basis

Theoretically, when a thread tries to obtain a mutex lock, but the lock is not successfully obtained by other threads, it immediately enters the sleep state, giving way to the CPU time, allow other threads to run. It will continue to sleep until it is eventually awakened, and the wake-up condition is that the thread that obtained the mutex lock has released the mutex lock;

In comparison, when a thread tries to obtain a spin lock, but the spin lock is not successfully obtained by other threads, it will get it again and again (called polling in English) until it is finally successful. Therefore, when obtaining the spin lock, the thread will not give up the CPU time, and other threads will not be able to run. Of course, the operating system will not allow a thread to keep blocking the operation of the entire system, after a thread spends its total CPU running time, it will force the switch to another thread for execution. (Note: You can view the maximum total CPU time used by a thread in seconds through ulimit-T)

Problem

For mutex locks, it is expensive to sleep the thread and wake up the thread. It requires a lot of CPU commands and takes a long CPU time. If thread a acquires the mutex lock and is released after holding the lock for a short period of time, thread B obtains the mutex lock, the time that the B-thread goes into sleep and the CPU time consumed by the wake-up may exceed the time that the B-thread goes to sleep, or even exceeds the polling time when the spin lock is used;

On the other hand, it takes a lot of CPU time to obtain the spin lock repeatedly. If thread a holds the lock for too long, the B thread that tries to obtain the lock will take a lot of CPU time. In this case, it will be better to sleep the B thread.

Solution

Do not use the spin lock on a single CPU Single-core system, because when thread a acquires the spin lock polling, it may block the only CPU and cause all other threads to be unable to run, other threads cannot run, which means that the thread B that needs to release the spin lock cannot run at CPU time, so the spin lock will not be released. That is to say, the spin lock wastes only the system CPU time and does not get any benefit (The condition for obtaining the lock is that after polling consumes the total CPU time, the system switches to the B thread, the lock is obtained only when thread a executes the lock again after thread B releases the lock ). If thread a enters sleep immediately when it cannot obtain the lock, thread B may be able to execute immediately. It is possible that thread B will immediately release the lock. After thread a is awakened, you can continue the execution.

In a multi-CPU and multi-core system, if a large number of locks are held for a short period of time, it will take a lot of time to continuously put the thread into sleep and wake up the thread, it may significantly reduce system performance. When the spin lock is used, the thread can use the CPU time slice they can use to immediately perform subsequent work after a short congestion, so as to maximize the CPU usage.

Practice strategy

In most cases, the programmer does not know whether to use a spin lock or a mutex lock (because he cannot know the number of CPU cores of the system running the program in advance ), the operating system cannot know whether a code segment is optimized to run in a single-core or multi-core environment. Most operating systems cannot strictly distinguish between mutex locks and spin locks. In fact, most modern operating systems use mixed mutex locks and mixed spin locks. Why?

The mixed mutex lock behavior is similar to the spin lock on the multi-core system at the beginning: If thread a cannot obtain the lock, it will not be immediately sleep, because the mutex lock may be released immediately, it may start with a spin lock. The A thread will be sleep only when it has not obtained the mutex lock after waiting for a long enough time. If the same program runs on a single-core system, the mutex lock will not spin because it has no benefit.

The mixed spin lock behavior is the same as the general spin lock at the beginning, but to avoid wasting too much CPU time, it may adopt a compromise policy: the system will not let the thread enter sleep (because you certainly do not want to sleep when the spin lock is used), but it will decide when to stop the thread for other threads to run (or immediately, or after a fixed period of time), the chance of unlocking the spin lock is increased. (Simple thread switching usually does not make the thread sleep and then wake up the thread)

Summary

If you are not sure, use mutex, which is usually a better choice. In the case that benefits can be gained, most modern operating systems will allow the mutex lock spin (polling) for a period of time. Using spin locks improves performance in some cases, but only under certain conditions. In fact, you are skeptical rather than telling me that you do not currently have any projects using spin locks that may benefit. You may use your own "Lock Object", which either uses a spin lock internally or uses a mutex lock (for example, the type of lock that can be configured during creation). At the beginning, mutex locks are used in all places. It may be helpful if spin locks are used in some places, try it and compare the results. before reaching a conclusion, make sure that you have tested the single-core and multi-core systems during the comparison. If your program is cross-platform, also, test various operating systems.

Original article: http://www.pixelstech.net/article/1397962421-Practice-of-using-spinlock-instead-of-mutex