Monday, September 13, 2010

[CS 704D] Mutual Exclusion and Trial Algorithms- 2


As we saw, the first trial algorithm forced a strict alternating access(round robin with more than two processes) to the two processes. The whole thing ran at the speed of the slower process and when one process crashes, it can block the other process forever.  Also any change in any one process needed careful changes in the other process. With more than two processes, that could be a handful.

The second attempt tries to remedy most of the problems. Let's take a look at that first before we see if this too has problems.(the pseudo code example from Operating Systems-MilanMilenkovic).

program/module mutex2
....

var
 p1using, p2using : boolean;  { in this version we have binary variable which show which process is in the CS]

process p1;
 begin
     while true do [ do this when the p1 has been initiated]
     begin
        while p2using do [keeptesting]; [Busy wait if p2 is using the CS]
        p1using :=true:    [set the flag that shows p1 is using the CS]
        Critical section
        p1using := false;   [clear the flag, let others use the CS]
        .........
        end {while}
 end{p1}



process p2;
 begin
     while true do     [ do this when the p2 has been initiated]
     begin
        while p1using do [keeptesting];   [Busy wait if p1 is using the CS]
        p2using :=true:    [set the flag that shows p2 is using the CS]
        Critical section
        p2using := false;     [clear the flag, let others use the CS]
        .........
        end {while}
 end{p2}

{parent process}

begin {mutex2}
     p1using :=false;   [ usage flags are turned off,  whichever process reaches the critical section can start]
     p2using := false:
     Initiate p1, p2   [p1 and p2 are initiated to start]
end {mutex2}

Now clearly there are no strict turn taking. depending on the speed at which p1 or p2 (or more of processes) operate, and controlled by the mutex the processes operate smoothly. One process crashing does not hold up the other processes No process needs to know what others are doing, any changes needed can be done by themselves. That is mush safer and cleaner way of doing things.

One of the conditions of a well behaved mutual exclusion is that no more than one process could be operating inside the critical section.This is how this can happen with this algorithm.

1. Both processes are outside of their respective critical sections
2. p1 checks p2using and it is free now, so p1 sets p1using and enters CS.
3.but if p2 preempts p1 before p1 could have set p1 using, then p2 will find it is ok to enter CS, sets p2using.
4. p1 resumes now (it has already found p2using to be false, so goes ahead and sets p1using to be true and enters the CS.

Now, that beats the main condition of mutual exclusion!
To be entirely safe the global variable p1 using and p2using should both be set inside the protection of mutex too.

No comments:

Post a Comment