Types of Locks

Types of Locks

Depending on the structure required to complete the task, an application may use many different types of lock primitives, so developers must avoid confusing the lock primitives in a given task, especially when using libraries provided by third parties. Suppose that in an application, Resource R relies on a third-party-provided library, and resource R in the library uses the L-lock as the synchronization primitive. At this point, if the developer needs to use the lock primitive for resource R in the application, it must also use L instead of other types of lock primitives. The next sections describe the different types of locks and describe their purpose in detail.

Mutex (mutex) mutex is the simplest type of lock, so some textbooks generally describe the lock primitive as an example of mutex. The release of the mutex does not depend solely on the release operation, but can also introduce a timer attribute. If a timer timeout occurs before the release operation executes, the mutex also frees the code block or shared storage for other threads to access. When an exception occurs, you can use the Try-finally statement to ensure that the mutex is freed. The use of Timer states or try-finally statements can avoid deadlocks.

Recursive lock (Recursive lock) A recursive lock is a type of lock that can be repeatedly acquired by the thread that currently holds the lock without causing the thread to produce a deadlock. In the case of recursive locks, other threads can acquire the lock only if there is a release action corresponding to the acquisition lock operation of the current holding thread. Therefore, when using recursive locks, it is necessary to use sufficient release lock operations to balance the acquisition lock operation, the best way to achieve this is to use the fetch and release operations at both ends of the single-entry single-exit code block one by one, as in normal locks. Recursive locks are most useful in recursive functions. However, in general, recursive locks are slower than non-recursive lock speeds. It is important to note that the calling thread obtains several recursive locks that must be released several times.
Figure 4-10 shows an example of the use of a recursive lock.

Recursive_lock L

void recursivefunction (int count) {

L->acquire ()

if (Count > 0) {

Count = count-1;

Recursivefunction (count);

}

L->release ();

}

Figure 4-10 Recursive Lock usage Example

The read-write lock (Read-write lock) is also known as a shared exclusive lock (Shared-exclusive lock), a read-write lock (Multiple-read/single-write lock), or a non-mutex semaphore (non-mutual Exclusion semaphore). A read-write lock allows multiple threads to read access at the same time, but only one thread can perform write operations at a time. Read-write locks are an efficient synchronization mechanism for applications where multiple threads need to read shared data at the same time but do not necessarily write. For longer shared data, setting only one read-write lock for it can result in longer access times, preferably dividing it into smaller segments and setting multiple read-write locks for synchronization.

Rotation lock (Spin lock) A rotation lock is a non-blocking lock that is exclusive by a thread. When a rotation lock is used, the waiting thread does not statically block at the synchronization point, but must "rotate", trying until the lock is finally acquired. Rotary locks are used in multi-processor systems. This is because if a rotation lock is used in a single-core processor, when one thread is "spinning", there will be no execution resources available to another thread that releases the lock. The rotation lock is suitable for any lock holding time less than the time required to block and wake up a thread. Thread-controlled changes, including thread-context switching and thread data structure updates, may require more instruction cycles than rotating locks. The hold time of the rotation lock should limit the time between 50% and 100% of the thread context switch (kleiman,1996 years). Threads should not hold rotation locks when calling other subsystems on a thread. Improper use of a rotating lock may cause the thread to starve, so use this locking mechanism with caution. The problem of starvation caused by rotation lock can be solved by using queuing technology, where each waiting thread rotates on a separate local identity in the first in, out order, or queue structure