Lock convoys explained

Lock convoys explained

Pan aimin, 2010-10-9

 

Lock convoys is a performance degradation problem caused by the use of locks in multi-thread Concurrent Environments. When multiple threads with the same priority frequently compete for the same lock, it may cause the lock convoys problem. Generally, the lock convoys will not stop the application logic like deadlock or livelock. On the contrary, the system or application suffering from lock convoys still runs forward. However, too many thread environment switches due to frequent lock contention among threads, which greatly reduces the system running efficiency, if there are threads that do not participate in lock competition at the same priority, they can obtain a relatively large number of processor resources, resulting in unfair system scheduling.

This article will explain the reason for the lock convoys problem.

 

Assume that a group of threads frequently obtain the lock (the so-called frequent lock refers to multiple times in the execution cycle of a time slice). For example, in Windows applications, the critical section is often used) to protect a shared variable or prevent a piece of code from being reinjected, this is very likely to happen. Assume that thread a gets the lock and thread scheduling is interrupted. The time slice of thread a is used up. Therefore, if the system scheduler is handed over to the next thread for execution, set thread B to obtain the execution right. Because this lock is obtained by thread A, when thread B executes the operation to obtain the lock, although the time slice is not used up, it has to give up the execution right. As a result, all threads with the same priority and competing for this lock are blocked. The scheduler returned to thread a again and soon thread a released the lock. In the operating system, releasing a lock means that if a thread in the kernel is waiting for the lock, its status can be changed to the running state. For example, thread B's acquisition operation is successful. But at this time, the kernel only marks thread B as the lock owner, and thread a continues to execute. Soon, thread a had to get the lock again. Because the lock has been marked to thread B, thread a had to give up the time slice and hand over the control to the scheduler. The scheduler can finally pick up thread B and give it the execution right of the processor. When thread B releases the lock, the next thread obtains the ownership of the lock, and then has the opportunity to be executed after thread B gives up the execution right or ends the time slice. This process continues, and after a round, it will return to thread a to continue the next round of competition. During this period, these threads always have to give up the execution right if they are not fully executed. The following figure shows the execution of the three threads when they compete for a lock.

Assume that a thread needs to obtain/release the lock Multiple times during the execution of a full time slice. Once the lock is released, it means that as long as there is lock competition, it can no longer obtain the lock in the current time slice allocated to it. Therefore, it can only be executed until its next get operation. For example, if the competing thread needs to obtain the lock for an average execution of 1/3 time slice, the actual execution time of the thread is changed to 1/3 time slice. The scheduling granularity of the system is changed to the original 1/3 interval. This results in thread switching by three times. From the right half, we can see that each thread has only 1/3 time slices in a round of loop. This leads to three times of thread switching.

In addition to reducing the scheduling granularity, another problem of lock convoys is that the time allocation of the scheduler is unfair. Assume that another thread x runs at the same priority but is not involved in lock competition. Therefore, in each round of lock competition, thread X has the opportunity to be allocated a complete time slice. Therefore, these competing threads obtain 1/3 time slice in a round, instead of competing threads, you can obtain the complete time slice. Of course, you can say that this type of unfairness is caused by their locks, but from the aspect of time allocation ratio, the threads involved in competition and not involved in competition are unfair. The execution time difference between threads X, A, B, and C.

From the above description, we can see that the condition of lock convoys is that the competing threads frequently obtain the lock. After the lock is released by one thread, its ownership will be placed in the hands of another thread. In the operating system, threads with the same priority are scheduled and executed in FIFO order, and the threads competing for the same lock are also successfully obtained in FIFO order. These conditions are met in modern operating systems, including windows.

Although lock convoys is not a fatal issue, it may also happen in the actual system. Sue LOH shows the lock convoy issue in Windows CE in her blog article [1. She also discussed a reasonable solution to relieve lock convoy, requiring that every thread first try the lock. If the attempt is still unsuccessful for multiple times, the lock will be blocked.

 

Note 1: There is very little information about lock convoys. on Wikipedia, there is only a very limited description [2]. The blog article [1] of Sue LOH provides a detailed description. In the next article, I plan to discuss the performance of lock convoys on the Windows platform (with Windows Server 2003 SP1 and wrk as references) and the thread execution path.

NOTE 2: For the Chinese translation of lock convoys, I saw a book translating it into "lock escort ". I personally think it is not very appropriate. It may be better to translate it into "lock protection" or "lock protection.

 

References:

[1] Sue Loh, lock convoys and how
Recognize them, http://blogs.msdn.com/ B /sloh/archive/2005/05/27/lock-convoys-and-how-to-recognize-them.aspx,
2005.

[2] Lock convoys, http://en.wikipedia.org/wiki/Lock_convoy