1. Mutex

1.1 What is a mutex

A mutex is an exclusive lock, and only one thread can access a shared data resource at a time. Each object should be assigned a tag, which can be called a "mutex lock", to mark that only one thread accesses this object at any time.

1.2 Why add a mutex

Multiple threads in a process share system resources. Multiple threads operate on an object at the same time. When the operation of one thread is not over, another thread also operates on it, resulting in an error. Therefore, the object to be operated needs to be processed. Add a mutex to ensure that each thread's operation on the object can get the correct result

1.3 How to solve multi-thread competition

Threads are not independent, data is shared, and there will be a state of competition when accessing at the same time, causing data confusion. This is the so-called thread unsafe

Solution: lock

Benefit: Atomic operation , complete execution of one of our threads from beginning to end
Disadvantages: The concurrent execution of multi-threads is organized, and a certain piece of code containing locks can actually only be executed in single-threaded mode, and the efficiency is greatly reduced

2. Deadlock

2.1 What is deadlock, example analysis

One situation is that thread A never releases the lock, and as a result, B has never been able to get the lock, so thread B is "dead"
In the second case, thread A owns the lock Y needed by thread B, and thread B owns the lock Y needed by thread A. At this time, thread A/B relies on each other to release the lock, so both "dead"
If a thread is always unschedulable, threads waiting for the result of this thread may be deadlocked. This situation is called thread starvation deadlock. For example, in an unfair lock, if some threads are very active, such threads may always obtain the lock under high concurrency, then those threads with low activity may never obtain the lock, thus starvation occurs

2.2 Necessary conditions for deadlock to occur

Mutually exclusive conditions: a resource can only be used by one process at a time
Request and hold conditions: When a process is blocked due to requesting resources, it will hold on to the obtained resources
Non-deprivation condition: The resources obtained by the process cannot be forcibly deprived before they are used up
Circular waiting condition: a number of processes form a head-to-tail circular waiting resource relationship.

2.3 How to solve, how to prevent deadlock?

Reboot is too expensive
Cancel all processes participating in the deadlock at one time, depriving all resources
Process rollback, ideal but more expensive, requires a large stack to record the changes of each step to achieve rollback

2.4 How to prevent deadlock

Request locks as much as possible in accordance with the lock usage specifications, and the lock request granularity should be small (don't occupy locks where locks are not needed, and release locks as soon as possible if they are not used);
Always use tryLock or a timing mechanism in advanced locks (that is, specify the time to acquire the lock timeout, if the time is up and the lock is not acquired, then give up

3. Spinlock

3.1 What is a spin lock? What are the characteristics

It is relatively resource-intensive for threads to switch between kernel mode and user mode. Therefore, it is necessary to reduce the switching of threads between blocking and waking up.

eg: If thread A holds the lock needed by thread B, thread B thinks that I have come here with great difficulty, and will let me enter the blocking wait again. I don't know when the CPU resources will be allocated next time, can I wait, maybe thread A will finish soon. The cpu said: Yes, but there is one condition, we do not keep idle threads, you must do something to prove your use. How about this, you can do a spin dance to cheer everyone up. Therefore, thread B keeps spinning until thread A releases the resource, and it immediately gets the lock resource and starts working.

advantage

Spin locks can reduce CPU context switching, and greatly improve performance for code blocks that occupy locks for a very short time or lock competition is not fierce, because the CPO time of spin is significantly less than that of thread blocking, suspending, and reawakening The time taken for two CPU context switches.

shortcoming

When the thread holding the lock occupies the lock for too long or the competition for the lock is too fierce, it will be a waste of CPU if the thread cannot obtain the lock resource for a long time during the spin process. Therefore, it is not suitable to use spin locks when there are complex lock dependencies in the system.

Refer to the original link: https://blog.csdn.net/qq_52563729/article/details/125828312

Linux multithreading (1) concept of mutex, deadlock, spin lock