Recursive locking of Linux thread synchronization

Overview

The most common process/thread synchronization methods are mutexes (or mutex), read-write Locks (rdlock), conditional variables (cond), semaphores (Semophore), and so on. In Windows systems, critical sections (Critical section) and Event objects (events) are also common methods of synchronization.

Simply put, a mutex protects a critical section, in which a maximum of one thread can be entered at a time. If multiple processes are active within the same critical zone, it is possible to generate a race condition (race condition) that causes an error.

Read-write locks are broadly logical and can be considered a shared version of the mutex. If the majority of a critical section is read and only a small number of write operations, read and write locks to some extent can reduce the cost of mutex.

A condition variable allows a thread to wait for a condition to occur in a way that is not competitive. When this condition does not occur, the thread is dormant all the time. When a condition has been notified by another thread, the thread is awakened and continues to execute downward. The conditional variable is the low-level synchronization primitive, which is used in a few cases, and is often used to achieve thread synchronization between the high-level. A classic example of using a condition variable is the thread pool.

In learning the operating system process synchronization principle, the most spoken is the signal volume. By carefully designing the PV operation of semaphores, it is possible to implement complex process synchronization situations (such as the classic philosophers dining problem and barber shop problem). But in the realistic program design, but very few people use the signal quantity. Problems that can be solved with semaphores seem to replace the semaphore with other clearer and more concise design methods.

The purpose of this series of articles is not to explain how these synchronization methods should be used (Aupe's book is clear enough). It is more about the concept of lock that is easy to be overlooked, as well as the more classical methods of using and designing. The article will involve recursive and non recursive locks (recursive mutexes and non-recursive mutexes), zone locks (Scoped Lock), policy locks (strategized locking), read-write locks and conditional variables, dual-detection locks (DCL), Lock-independent data structure (locking free), spin lock, etc. content, hope to be able to initiate.

So let's start with a recursive lock and a non recursive lock:

1 recursive and non-recursive locks

1.1 Concepts

In all thread synchronization methods, it is feared that the appearance rate of mutex (mutex) is much higher than that of other methods. Mutual-exclusion locks are easy to understand and basic to use, not to be introduced here.

Mutexes can be divided into recursive locks (recursive mutexes) and non-recursive locks (non-recursive mutexes). A recursive lock can also be called a reentrant lock (reentrant mutex), which is not a recursive lock (non-reentrant mutex).

The only difference is that the same thread can get the same recursive lock multiple times without creating a deadlock. A deadlock is generated if a thread acquires the same non-recursive lock more than once.

The mutex and critical section under Windows are recursive. Linux pthread_mutex_t locks are not recursive by default. You can display the settings Pthread_mutex_recursive property and set the pthread_mutex_t to a recursive lock.

In most articles and books that introduce how to use mutexes, these two concepts are often overlooked or understated, causing many people to have no idea of the concept at all. However, if these two kinds of locks are misused, it is likely to cause a deadlock in the program. Please see the following procedure.

Mutexlock Mutex;    
        
void foo ()    
{    
    mutex.lock ();    
    Do something    
    mutex.unlock ();    
}    
        
void Bar ()    
{    
    mutex.lock ();    
    Do something    
    foo ();    
    Mutex.unlock ();     
}

The Foo function and the bar function both acquire the same lock, and the bar function calls the Foo function. If the Mutexlock lock is not a recursive lock, the program will immediately deadlock. So be careful when locking a piece of program, otherwise it's easy to deadlock because of this call relationship.

Don't be lucky, think this is a rare occurrence. This error can easily be made in a program when the code is complex to a certain extent, is maintained by multiple individuals, and the call relationship is intricate. Fortunately, the deadlock caused by this reason is easily excluded.

However, this does not mean that recursive locks should be used instead of non recursive locks. Recursive locks are simple to use, but they tend to hide some code problems. For example, the call function and the called function think that they have got the lock, are modifying the same object, then it is very easy to problem. Therefore, if you can use a non-recursive lock, you should try to use a non-recursive lock, because deadlocks are relatively easier to find through debugging. If there is a problem with the program design, the sooner it should be exposed, the better.