Operating system principle--dekker mutual exclusion algorithm detailed

Dekker Mutual Exclusion algorithm detailed

Hello everyone, this is my first technical blog (also the first blog), has seen "a programmer's struggle history", thus initiation of the idea of blogging. I am currently learning the embedded direction, is a no-compromise bird. This blog is also from my study of computer operating system principles in the process of summarizing the results (video download address http://xidong.net/File001/File_53948.html). If someone is learning something about it, I really want to be able to help you. If there is a wrong place, please point out and correct.

Most systems allow multiple processes to share resources (such as cpu,io devices, hard disks, and so on), and to ensure that the shared resources are securely and correctly accessed between processes, there must be some control over the process access shared resources. A shared resource that allows only one process access at a time is called a critical resource, and the program snippet that accesses those critical resources is called a critical section. In computer terminology, this control of the process's access to critical resources is called mutual exclusion (that is, the process of a critical section of a moment can only be a single one).

There are many methods to solve the process mutex, such as software method, hardware method, semaphore method, enhancement and so on, and the Dekker mutex algorithm which I call today is one of the software methods.

Rookie idea: Let's first look at the pseudo-code of the simplest mutually exclusive access critical section that a beginner can think of:

Beginners See this code, some people may find it strange. When flag is initialized to 0 and then executes the process method, the while judgment does not pass, so the subsequent code executes, and the last method ends with the value of flag still 0, which is not equal to the while loop body never executes ... Attention.. You can no longer use single-process programming as a piece of code to execute the "straight line" thinking from the ground up. This is a multi-input (line) program. It is entirely possible for a program to be interrupted when it executes to any one statement, skipping to another process to execute another piece of code.

In the above code, a state value is used to determine whether a process can enter the critical section, when a program enters the critical section, the flag is changed to busy, and then the critical section is reset to idle, freeing up resources. On the surface it seems to be mutually exclusive (when a process is blocking other processes from entering in the critical section). But look carefully, in fact, the above code did not achieve mutual exclusion function ... Why is it. Take a break first. When I talk about the improvement of Vision 1 , I'll say why. ^_^

In short, the above code does not achieve the function we need, then I will now introduce a good solution to the mutex function of the code (just to solve the mutex), this is the initial idea.

initial assumption: The code Presents:

Notice this code, in fact, the idea of this code is very clear: set each process to access the critical section of a sequence number, each process must follow the ordinal access to the critical section. Seems to be mutually exclusive. Indeed, he was perfectly mutually exclusive, that's all. The procedures strictly follow a certain order (0->1->0->1 ...) to access the critical section, so that when a process enters the critical section, there is absolutely no chance of entering the critical zone to other processes. Why is it. Also wait until the improvement Scenario 1 to say why. ^_^

The better-off students will surely notice that this leaves several deadly problems: first, the two processes that access the critical section depend entirely on each other's modifications to the number value, assuming that a process has an error exiting the process before it modifies the ordinal value to the ordinal value required by the other process. Then the sequence number will never be modified, then the process dependent on this ordinal value will never be executed. This is very deadly, it violates the process of "limited waiting, idle let in" principle of mutual exclusion. In addition, when the frequency of two processes accessing critical resources is not the same, it will seriously affect system efficiency. For example, process 0 accesses the critical section every 1 minutes, and Process 1 accesses the critical section every 10 minutes. When process 1 exits the critical section, the critical section is not entered until 10 minutes, and every minute of process 0 enters the critical section, but when process 0 exits the critical section, it must wait until process 1 exits the critical section, and process 1 does not need to enter the critical section. Process 0 must wait 9 minutes after the critical section is idle for the critical section to be accessed by process 1 and exit before entering, and waiting for one 9 minute for each cycle. In other words, a process with low frequency of access seriously affects the execution efficiency of high-frequency processes, which clearly violates the principle of "idle-in".

Perhaps the rookie (I also) on the above statement, understanding is not too clear. Here I would like to compare such an example: the above situation as if two people want to enter a squat in a toilet, there is a big uncle at the door to a number of two people are given a card (0, 1), and the provisions must follow the "01010101 ..." Rules into the toilet. If the person a in the toilet when a careless will number card 0 into the sewer, then people B is tragic, because the gate of the uncle is very strange, he will always wait until the number card 0 from the toilet out to let people b in .... In another case, if a person a toilet every day, and people b kidney function is not very good every 5 minutes on the toilet, then people a after the toilet, people B also after the first time after the toilet ... Oh, my God. It is strange that he should not suppress death.

Now you should know the hateful place of this system, somewhere in the initial idea There are so many drawbacks, the following is the first improvement.

Improvement Scenario 1: The code is as follows:

The improvement Scenario 1 eliminated the initial idea of the serial number access, making most of the above issues resolved. This method is in fact similar to the rookie idea, they give the critical section a state identification, when the identification is free to allow the process to enter, so that the critical area is fully utilized, the different place is to improve the assumption 1 state information more accurate, it makes the program know which process occupies the critical area, increased the flexibility of programming, But it restricts the use of the mutex algorithm: only two processes can be controlled mutually exclusive operation, in fact, this is one of the shortcomings of the Dekker algorithm.

Unfortunately, the improvement Scenario 1 , like the rookie idea , also fails to achieve true mutual exclusion. As I mentioned earlier, the concurrency of multiple processes is uncertain, and process switching may be ongoing during program execution. Let's take a look at the situation where process 01 finishes (1), because Flag[1] is initialized to 0, skips over the loop body, prepares to start Execution (2), when the process is suddenly switched to execute Process 1, until process 1 executes to (3), because (2) is not executed, flag[0 ] The value has not been modified, or the initial value of 0, the result of process 1 also bypassed the loop body successfully entered the critical section, which led to process 0 and process 1 at the same time into the critical section, so that mutual exclusion failure. The same goes for the rookie's idea of making this deadly mistake. But why the serial number access can be a smooth mutual exclusion. This is because regardless of the switch, the value of number is not 0 is 1, which determines the two while loop (a judgment is 0, a judgment is 1) only one can smoothly "bypass" the loop body, and enter the critical section, thereby achieving mutually exclusive access.

Back to the example of my analogy, just like the toilet has a light, used to indicate whether there are people in the toilet, when the person outside the toilet to see the lights are bright means that there is someone inside the toilet, the other hand means that no one can enter. At this time if the person a saw the signal is black, in after not come in urgent to press the signal switch, and at this moment just people B saw the light is black, so also entered the toilet, then, embarrassed ...

It can be seen that due to the uncertainty of the process switching, the process enters the critical area at the same time, and the reason of the above situation is that the "timing" of the modified state is wrong, so there is an improvement scenario 2.

Improvement Scenario 2: The code is as follows:

Improvement Scenario 2 Put the modification of the state before the loop, that is, the process accesses the critical section in advance to express the "will" to access the critical section, so that no matter how the process switches until one of the processes starts to perform the loop condition judgment, either only one flag is 0, or two are 1, This ensures that two processes cannot bypass the loop body at the same time. But the attentive person will find this problem: when Process 01 is finished (1), because Flag[1] is initialized to 0, thus skipping the loop body, ready to start Execution (2), when the process is switched to process 1, and so on (1) Process 3, and then be switched back to process 0 execution, and at this time flag[1] is modified to 1 to meet the loop condition into the loop body, at a time in the loop and switch to (4) execution, also because Flag[0] was modified to 1 into the loop body, the result is conceivable, two processes have entered the loop body and can not modify their status values, resulting in two processes can never jump out of the loop. This situation is called a "deadlock" in the computer, unless a process actively abandons the resource, or the system actively intervenes, the process always takes up resources but does not advance.

With the toilet analogy, this method is to give everyone a remote control, so that it can be used to remotely light the signal before entering the toilet, so as to avoid entering the toilet at the same time, but if people a lit up their own lights, but have not had time to enter the toilet, people b also not to be outdone by the light of their own lights, Two of people are not humility, resulting in no one can enter the toilet ...

It can be seen that the above problems occur in the root knot, because two processes are in advance to express the attempt to enter the critical area, but who will not give up their willingness to enter the critical area, do not compromise, and constantly check the status value, resulting in deadlock.

Improvement Scenario 3: The code is as follows:

The idea of improvement is very simple, so that the process in the discovery of the other side into the critical area of the desire to stop their own will be a random length of time, so as to achieve mutual humility to express their own will. In this way, even if the two-way process at a certain moment because the other party's status value is 1 and all entered the while loop body, but because the process will abandon the intention to make a process always because the cycle conditions do not meet the loop, thus entering the critical section. Since the stop time is random, it may go through many cycles to determine the state of the other side is 1, but there will always be a moment

The implementation of the two processes will be staggered, so that the two sides of the cycle to judge the time will not be two flag is 1. Although this method does not enter the deadlock, but there is a very low probability of occurrence of the deadlock, that the two sides after humility may be at the same time the cycle of judgment, so that time and again the humility, resulting in reduced program efficiency, and even the two sides of the humility caused two of the process of blocking time close to the infinite situation.

Then use the toilet example to illustrate: people A and b see each other into the toilet lights are lit, they are actively polite humility, turn off their lights, but, two people are too tacit understanding, two people are at the same time turn off the lights, and in the same moment to turn on the lights, double hair so always let go, The two men were so deadlocked for a long time that no one was able to enter the critical section ...

However, the program design must be absolutely rigorous, although in the case of stopping a random time, two processes still maintain "synchronous propulsion" situation is very small, but even if the possibility of%0.00...001 the program deadlock, then the design is imperfect. In order to completely eliminate the possibility of this impasse, it was born the final algorithm is also the famous Dekker mutex algorithm. (sorry, this paragraph, really do not know how to express to be easy to understand)

final assumption (Dekker mutex algorithm):

Dekker Algorithm finally came out, you can see that the Dekker algorithm is based on the improvement of the concept of 3 humility, a "modest but not excessive humility" of the compromise thought. How to avoid the constant humility of both sides. Dekker Algorithm uses the initial idea of the sequence number to access the idea, so that the process of entering the cycle in accordance with the sequence number to decide whether or not to be humble, some people will ask, the use of serial number of the process appears in accordance with the serial number to access the critical area of the bad. The answer is no, at least not strictly in accordance with the serial number in turn access to the critical section, because, according to the number to humility has a precondition: two process must be because the other state value is busy and at the same time into the loop body, and before this, two processes into the critical area of the probability is the same, and the sequence is not related In other words, it also requires a bit of "luck" to access the critical section by ordinal.

In short, theDekker algorithm first uses the state value of the way to solve the problem of the critical section of the ordinal access, and the use of improved thinking 2 so that the process can be mutually exclusive access to critical resources, while the improvement of the idea 3 method to avoid the deadlock phenomenon, And finally combined with the serial number of humility to solve the deadlock caused by avoiding deadlock phenomenon, so gradually using software method to solve the problem of mutual exclusion of the process.

However, the Dekker method is really perfect. Unfortunately, even the Dekker algorithm can not avoid the software mutex method of a common problem, that is busy and so on. It is important to note that in each of these scenarios, the while loop is indispensable, and the execution of the loop body is meaningless code, which means that the software method uses a meaningless loop to make the process impossible to move forward to achieve the blocking process. However, allowing the CPU to execute meaningless code itself is a serious waste of resources, the process takes up the CPU, but does not produce any valid data, it can be said that this greatly reduces the efficiency of the CPU. This is an issue that cannot be avoided by the entire software approach.

In addition, we can see that the Dekker algorithm can only make two processes of mutual exclusion, for more than two mutual exclusion problems, the implementation is quite complex.

And, the software method in the implementation of mutual exclusion, need to be very careful, a little is mutual exclusion failure, deadlock, and so on.

The first blog finally finished writing, after writing it always feel too verbose, and some places always feel not explained too clear, it seems that some things really imaginative achievement here inexpressible ah, if there are readers think there is something wrong, or need to add what, welcome to spray. Thank you.