C # Multithreading series (v)

dead Lock

For thread safety, we need to use an "exclusive lock", but too many locks can be troublesome. We call deadlocks because of the deadlock caused by multiple threads waiting for competing resources to wait for each other. Without external force, these processes will not be able to advance. In a deadlock, at least two threads are suspended and waiting for the other to unlock.

Let's look at a small example: there are a lot of squares on a plane, and some stars move around. The basic rule is that each block can have only one star.

(Fig. 1)

Move the process such as, small black want to move from A2 block to A3 block. At this time the small black occupy A2 position, when the A3 position is empty, jump over.

(Fig. 2)

When the target position that you want to move is occupied by other stars, wait for the other stars to move over. such as small green, will wait until the small black removed and then moved to A2.

(Fig. 3)

But when the small black want to move the target position is B2 tragedy, stubborn star small black and small green will wait for each other to remove, until forever.

(Fig. 4)

May appear more complicated situation, small black in wait for Little red to remove, small red in waiting for small blue to remove, small blue in waiting for small green to remove, small green in waiting for small black to remove. This is a stalemate!

(Fig. 5)

or more complex cases (brain tonic) ...

conditions that create a deadlock

A deadlock must meet the following four conditions, so long as any of these conditions are not true, the deadlock will not occur.

• Mutex condition: The process requires exclusive control over the allocated resources, that is, for a period of time, a resource is occupied by only one process. If another process requests the resource, the request process can wait only. The corresponding example is that each block can only accommodate the next star.
• No deprivation condition: the resource obtained by the process cannot be forcibly taken away by other processes until it is exhausted, i.e. it can only be freed by the process that obtains the resource (only active release). The corresponding example is that the star can only wait for the target to go, but not to push it down the block.
• Request and hold condition: The process has maintained at least one resource, but a new resource request has been made, and the resource has been occupied by another process, at which point the request process is blocked, but the resources it has obtained remain. Our example is that the star has to occupy a block and then find the target block.
• Cyclic wait Condition: there is a cyclic wait chain for a process resource, and the resources that each process has obtained are requested by the next process in the chain.

Prevent deadlocksFrom our example, we can think of the method is: 1. Let the stars only jump in order, for example, the order is a0...an ... B1...bn ... c1...cn. Of course, a capable star can leap across, for example, from A0 to C1, but not against the reverse order. When you want to go back, you have to get off the block (release the lock) and start from the beginning. 2. When the star wants to move the target position is occupied by other stars, wait for other stars to move before moving past. This is the movement rule of the stars, we can add a time limit here, when the waiting time exceeds the timeframe, the star will run "rest", the star is the first block (release lock), rest for a period of time before continuing. 3. If the star's mobile line is relatively simple, such as moving only 5 steps each time, you can use a predetermined method. When the star starts moving, it locks all the blocks that will move. 4. Change the basic movement of the star, for example, from A0->A1, move the process to change, first down the block A0 (release resources), and then to A1. 5. On the basis of 4 improvement, each time the next block is more inconvenient, so we changed to, when the need to wait for the moving target block on the star to remove the first block. 6. Find a manager, when found to lock the dead, the stubborn stars are called under the block. Let each star wait for some time to continue.

The 1th scenario: Sequential locking is an effective mechanism for deadlock prevention. However, this approach requires you to know all the locks that may be used in advance, but there are always times when they are unpredictable. The basic idea is to destroy the necessary conditions to create a deadlock-the cyclic waiting condition.

The

2nd option is to add a timeout when attempting to acquire a lock, which means that the thread will discard the lock request if it exceeds the time limit in the attempt to acquire the lock. If a thread does not successfully acquire all the required locks within a given time frame, it will rollback and release all acquired locks, and then wait for a random time to retry. This random wait time gives other threads a chance to try to acquire the same locks, and allows the thread to continue running without acquiring the lock (the lock timeout allows you to run the rest of the work and then go back and repeat the previously locked logic). This is a kind of prevention, not broken necrosis lock necessary conditions. Also, if multiple threads are requesting several resources at the same time, because of the same number of waiting times, they are prone to repeated attempts and are never locked.

3rd scenario: This scheme is more violent and eliminates deadlocks. But if a thread needs a lot of resources, it's a waste of time. and is easy to appear, because some one or two resources required cannot be met without allocating resources.

4th, 5 scenarios: This scheme destroys the necessary conditions for the creation of deadlocks--request and hold condition. But it's not always possible to do so.

6th scenario: This is the deadlock detection, when the deadlock is detected when processing.

One possible option is to release all locks, rollback, and wait for a random time to retry. This is similar to a simple lock-out timeout, except that a deadlock has occurred before it can be rolled back, not because the lock request timed out. There are fallback and wait, but if there are a large number of threads competing for the same locks, they will still be deadlocked repeatedly.

A better solution is to prioritize these threads so that one (or several) of the threads fall back and the rest of the threads continue to hold the locks they need, just as they do without a deadlock. If the priority given to these threads is fixed, the same batch of threads will always have a higher priority. To avoid this problem, you can set a random priority when a deadlock occurs.

C # Multithreading series (v)