General description of boost mutex

Anyone who has written multi-threaded programs knows that it is critical that multiple threads cannot simultaneously access shared resources. If a thread tries to change the value of the shared data, and another thread tries to read the value of the shared data, the result will be undefined. In order to prevent such incidents, some extraordinary primitive data types and operations are required. The heaviest one is the abbreviation of mutex ("Mutual Exclusion. Mutual exclusion is often translated as "mutex "). Mutex can only allow one thread to access Shared resources at a time. When a thread needs to access shared resources, it must first "Lock" the mutex. If any other thread has locked the mutex, this operation will be blocked all the time, until the mutex thread is locked to unlock, this ensures that resources are shared. At the same time, only one thread can access the resources.

 

The concept of mutex has several variants. Boost. threads supports two types of mutex: simple mutex and recursive mutex. A simple mutex can only be locked once. If the same thread tries to lock the mutex twice, a deadlock will occur. For recursive mutex, a thread can lock a mutex multiple times, but it must be unlocked with the same number of times. Otherwise, other threads cannot lock the mutex.

 

Based on the above two types of mutex, how a thread locks a mutex is also somewhat different. A thread has three possible methods to lock the mutex:

1. Wait and try to lock the mutex until no other threads lock the mutex;

2. Try to lock mutex and return immediately. If other threads lock mutex;

3. Wait and try to lock the mutex until no other threads lock the mutex or until the specified time has elapsed.

 

It seems that the best mutex type is recursive mutex, because it supports the above three locking methods. However, different locking methods consume different resources. Therefore, for specific applications, boost. threads promises you to select the most efficient mutex. To this end, boost. threads provides mutex of Type 6, which is arranged in a descending order of efficiency: boost: mutex, boost: try_mutex, boost: timed_mutex, boost: recursive_mutex, boost :: recursive_try_mutex and boost: recursive_timed_mutex.

 

If a thread locks a mutex and does not unlock it, a deadlock occurs. This is also the most common error. For this reason, boost. threads is specially designed to avoid locking or unlocking mutex directly to make this error impossible (or at least difficult ). Instead, the mutex class defines the embedded typedef to implement raiI (resource acquisition in Initialization) [4] To lock or unlock a mutex, this is the so-called scoped lock mode. To construct a lock of this type, you need to transmit a mutex reference. The constructor will lock the mutex and the Destructor will unlock the mutex. The C ++ language specification ensures that the Destructor is always called, so even if an exception is thrown, the mutex will be correctly unlocked.

 

This mode ensures the correct use of mutex. However, it must be clear that although the scoped lock mode ensures that the mutex is correctly unlocked, it cannot ensure that all shared resources are in a valid State when an exception is thrown. Therefore, just like single-threaded programming, you must ensure that exceptions do not bring programs in an inconsistent state. At the same time, lock objects cannot be transferred to another thread because the state they maintain is not protected by this usage.