Mutex lock, spin lock, read-write lock... Clarify their differences and applications

Reprinted address ：https://baijiahao.baidu.com/s?id=1712307590984312649&wfr=spider&for=pc

In life , We will use locks to protect our property from being stolen , But today's talk “ lock ”, Not for this purpose .

In the world of programming , How to use locks well is one of the basic qualities of programmers . When multithreading accesses shared resources , We can't avoid the problem of data disorder caused by resource competition , Usually in order to solve this problem , Will lock before accessing shared resources . The most commonly used is mutex , Of course, there are many different kinds of locks , For example, spin lock 、 Read-write lock 、 Optimistic lock, etc , Different types of locks are naturally suitable for different scenarios .
If the wrong lock is selected , In some highly concurrent scenarios , May reduce the performance of the system , Impact on user experience . In order to choose the right lock , Not only do you need to know the cost of locking , You also need to analyze how shared resources are accessed in business scenarios , Then we should consider the conflict probability of concurrent access to shared resources . An antidote against the disease , To reduce the impact of locking on high concurrency performance .

Read-write lock (RWMutex)
Read / write locks are mutually exclusive locks for read / write operations . The biggest difference between it and ordinary mutexes is , It can lock and unlock for read operation and write operation respectively . Read and write locks follow different access control rules than mutex locks . Within the jurisdiction of the read-write lock , It allows any read operation to be performed at the same time . But at the same time , It allows only one write operation in progress . also , In the process of a write operation being performed , Reading operation is not allowed . in other words , Multiple write operations under the control of read-write lock are mutually exclusive , And write operations and read operations are mutually exclusive . However, there is no mutually exclusive relationship between multiple read operations . Read the lock : be-all goroutine Can read at the same time , But write lock is not allowed : Only one is allowed goroutine Write , Other goroutine It is not allowed to read or write golang To demonstrate the function of read-write lock , as follows ：

The mutex (Mutex)
Use mutexes （Mutex, Full name mutual exclusion） To protect a resource from conflicts caused by concurrent operations , Leading to inaccurate data . The bottom two differences between mutex and spin lock are 「 Mutexes and spinlocks 」, Many advanced locks are implemented based on them , They can be considered as the foundation of various locks , So we have to know the difference and application between them . The purpose of locking is to ensure that shared resources can be locked at any time , Only one thread accesses , In this way, we can avoid the problem of data sharing disorder caused by multithreading . When a thread is already locked , Locking other threads will fail , Mutexes and spinlocks have different ways to handle lock failures .

The overhead cost of mutexes and spinlocks

After the mutex locking fails , The thread will release CPU , To other threads ; After the locking of the rotary lock fails , The thread is busy waiting , Until it gets the lock ; Mutex is a kind of 「 An exclusive lock 」, For example, when a thread A After locking successfully , At this point, the mutex has been locked by the thread A Exclusive , Just threads A No release of the lock in your hand , Threads B Locking will fail , And then it will release CPU Give way to other threads , Since threads B Released CPU, Natural threads B Lock code will be blocked . For mutex locking failure and blocking phenomenon , It's implemented by the operating system kernel . When the lock fails , The kernel will set the thread to 「 sleep 」 state , When the lock is released , The kernel wakes up threads at the right time , When the thread successfully acquires the lock , You can continue to execute .

Optimistic lock and pessimistic lock
The mutex mentioned earlier 、 spinlocks 、 Read-write lock , All belong to pessimistic lock . Pessimistic lock is more pessimistic , It believes that the probability of multiple threads modifying shared resources at the same time is relatively high , So it's easy to get into conflict , So before accessing shared resources , Lock it first . Contrary , If multiple threads modify shared resources at the same time, the probability is relatively low , You can use the optimistic lock . Optimistic lock is more optimistic , It assumes that the probability of conflict is low , The way it works is ： First modify the shared resources , There is no conflict in this period of time , If no other thread is modifying the resource , Then the operation is finished , If you find that other threads have modified this resource , Just give up this operation . How to try again after giving up , This is closely related to the business scenario , Although the cost of retrying is high , But if the probability of conflict is low enough , It's still acceptable . so , The attitude of optimistic lock is , It doesn't matter , Change the resources first . in addition , You will find that optimistic lock is not locked in the whole process , So it's also called lockless programming .

for instance ： Online documents can be edited by multiple people at the same time , If pessimistic locks are used , As long as one user is editing the document , At this time, other users cannot open the same document , Of course, the user experience is not good . Realize multi person editing at the same time , It's actually an optimistic lock , It allows multiple users to open the same document for editing , After editing and submitting, verify whether the modified content has conflicts . How to calculate a conflict ？ Here's an example , Such as user A First edit the document in the browser , After that users B The same document is opened in the browser for editing , But users B Compared with users A Submit changes , In this process, users A I don't know , When A When submitting the revised content , that A and B There will be a conflict between parallel modifications . How does the server solve this conflict ？ Because the probability of conflict is low , So let the user edit the document first , But the browser will record the version number of the document returned by the server when downloading the document ; When a user submits a change , The request sent to the server will carry the original document version number , The server receives it and compares it with the current version number , If the version number is consistent, the modification is successful , Otherwise the submission fails . actually , common SVN and Git It's also the idea of optimism lock , Let the user edit the code first , And then when you submit it , Determine whether there is a conflict by the version number , Where there was a conflict , We need to modify it ourselves , And resubmit . The optimistic lock removes the lock unlock operation , But in case of conflict , The cost of retrying is very high , So only when the probability of conflict is very low , And the locking cost is very high , Just consider using optimistic lock .