Multithreading-Types of locks

Multithreading-type of lock December 30, 2009 Wednesday 1:59

type of lock 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 third-party-provided libraries. Suppose that in an application, Resource R relies on a library provided by a third party, and resource R in that library uses an L-lock as the synchronization primitive. At this point, if the developer needs to use the lock primitives 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. Mutual exclusion (mutex) mutexes are the simplest types of locks, so some textbooks generally use mutexes as examples to describe the lock primitives. The release of the mutex does not depend solely on the release operation, but it 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 store 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 the timer state or the try-finally statement avoids the creation of deadlocks. Recursive locks (recursive lock) recursive locks are those that can be repeatedly fetched by the thread that currently holds the lock, without causing the thread to produce a deadlock type. For recursive locks, the lock is only available to other threads if the current holding thread's fetch lock operation has a corresponding release operation. Therefore, when using a recursive lock, you must balance the fetch lock operation with sufficient release lock operations, the best way to achieve this is to use the fetch and release operations at both ends of the single entry exit code block, as in normal locks. Recursive locks are most useful in recursive functions. In general, however, recursive locks are slower than non-recursive locks. It should be noted that the calling thread obtains several recursive locks and must release several recursive locks. Figure 4-10 shows a use example 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 Read-write locks (read-write lock) read-write locks are also known as shared exclusive locks (shared-exclusive Lock), read-only single write locks (Multiple-read/single-write lock), or non-mutex semaphores (non-mutual Exclusion semaphore). Read-write locks allow multiple threads to read at the same time, but at a certain point only a single thread can perform a write operation. 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 long shared data, setting a read-write lock for it will result in a longer access time, preferably dividing it into smaller segments and setting multiple read-write locks for synchronization. A rotation lock (Spin lock) rotation lock is a non-blocking lock that is monopolized by a thread. When a rotating lock is used, the waiting thread does not statically block at the sync point, but must "rotate" to keep trying until the lock is finally acquired. Rotary locks are used in multiprocessor systems. This is because if a spin lock is used in a single core processor, when a thread is "rotated", there will be no execution resource to use for another thread to release the lock. A rotation lock is suitable for any lock holding time less than the time required to block and wake a thread. Thread-controlled changes, including the switching of thread contexts and the updating of thread data structures, may require more instruction cycles than spin locks. The holding time of the rotation lock should limit between 50% and 100% of the thread context switching time (kleiman,1996 years). When a thread calls another subsystem, the thread should not hold a spin lock. Improper use of rotating locks can cause threads to starve to death, so use this locking mechanism with caution. The problem of starvation caused by rotating locks can be solved by queuing technology, in which each waiting thread rotates on a separate local identity in the order of FIFO or queue structure.

Category: Operating system-process-Threads | | Add to Search | Share to I bar | browse (3277) | Comments   (0)   Previous: Linux system under the mysql++ installation and make ...     Next: C language How to use macros including single double well number ...