Operating Systems: Sync Synchronisation Processes compete for resources - time, memory etc., but sometimes need to cooperate: to synchronise some activity e.g. updating bank balances to share a common resource

Example: inter-process communication Operating Systems: Sync Example: inter-process communication message passing via kernel process sends message to another process using system calls receiving process polls kernel for a message, or suspends itself until a message arrives, then re-activated by kernel continues processing but is signalled by kernel when a message arrives processes cooperating using a shared area of memory as a buffer sending process writes into buffer, receiving process reads from buffer kernel system calls not needed but what if several processes are sending messages to one process? how to synchronise writing into buffer? sending processes must have exclusive access to buffer while writing processes must cooperate

Railways in the High Andes Operating Systems: Sync Railways in the High Andes High in the Andes mountains, there are two circular railway lines. One line is in Peru, the other in Bolivia. They share a common section of track where the lines cross a mountain pass that lies on the international border (near Lake Titicaca?). Unfortunately, the Peruvian and Bolivian trains occasionally collide when simultaneously entering the common section of track (the mountain pass). The trouble is, alas, that the drivers of the two trains are both blind and deaf, so they can neither see nor hear each other.

Operating Systems: Sync The two drivers agreed on the following method of preventing collisions. They set up a large bowl at the entrance to the pass. Before entering the pass, a driver must stop his train, walk over to the bowl, and reach into it to see it it contains a rock. If the bowl is empty, the driver finds a rock and drops it in the bowl, indicating that his train is entering the pass; once his train has cleared the pass, he must walk back to the bowl and remove his rock, indicating that the pass in no longer being used. Finally, he walks back to the train and continues down the line. If a driver arriving at the pass finds a rock in the bowl, he leaves the rock there; he repeatedly takes a siesta and rechecks the bowl until he finds it empty. Then he drops a rock in the bowl and drives his train into the pass. A smart aleck graduate from the University of La Paz (Bolivia) claimed that subversive train schedules made up by Peruvian officials could block the train forever. Explain The Bolivian driver just laughed and said that could not be true because it never happened. Explain Unfortunately, one day the two trains crashed. Explain

Operating Systems: Sync Following the crash, the graduate was called in as a consultant to ensure that no more crashes would occur. He explained that the bowl was being used in the wring way. The Bolivian driver must wait at the entry to the pass until the bowl is empty, drive through the pass and walk back to put a rock in the bowl. The Peruvian driver must wait at the entry until the bowl contains a rock, drive through the pass and walk back to remove the rock from the bowl. Sure enough, his method prevented crashes. Prior to this arrangement, the Peruvian train ran twice a day and the Bolivian train ran once a day. The Peruvians were very unhappy with the new arrangement. Explain The graduate was called in again and was told to prevent crashes while avoiding the problem of his previous method. He suggested that two bowls be used, one for each driver. When a driver reaches the entry, he first drops a rock in his bowl, then checks the other bowl to see if it is empty. If so, he drives his train through the pass. Stops and walks back to remove his rock. But if he finds a rock in the other bowl, he goes back to his bowl and removes his rock. Then he takes a siestas, again drops a rock in his bowl and re- checks the other bowl, and so on, until he finds the other bowl empty. This method worked fine until late in May, when the two trains were simultaneously blocked at the entry for many siestas. Explain

The Producer/Consumer Problem Operating Systems: Sync The Producer/Consumer Problem Producer process generates items for Consumer process to deal with items consumed in same order as produced each process may work at different rates, each as they desire First-In-First-Out (FIFO) buffer shared between the two processes producer consumer

Shared circular buffer : buffer [ 0 : max-1 ] Operating Systems: Sync Shared circular buffer : buffer [ 0 : max-1 ] max-1 1 max-2 2 get put count

Operating Systems: Sync Producer process: while (TRUE) { prod_item = next to be generated; . . . . while (count==max) { // wait until count<max } buffer[put] = prod_item; put = (put+1)%max; count = count+1; Consumer process: while (TRUE) { while (count==0) { // wait until count>0 } cons_item = buffer[get]; get = (get+1)%max; count = count-1; process new item; . . . .

Operating Systems: Sync Problem statements: count = count+1; and count = count-1; not indivisible statements compile to: load reg, count load reg, count add reg, #1 sub reg, #1 store reg, count store reg, count on a single-processor, can regard each instruction as indivisible order of execution could be: load reg, count add reg, #1 load reg, count sub reg, #1 store reg, count store reg, count on a multi-processor, processes could be executing simultaneously How can processes be organised to share memory and also synchronise?

The Mutual Exclusion Problem Operating Systems: Sync The Mutual Exclusion Problem Each process has a critical section Criteria required to be met for a valid solution No two processes may simultaneously be inside their critical section No assumptions may be made about speeds of execution No assumptions about the number of processors No process running outside its critical section may block other processes No process should have to wait forever to enter its critical section (under the assumption that no process stays in its critical section forever) Is there a solution not involving special action by the kernel?

Operating Systems: Sync Disabling interrupts? Switch interrupts off at start of critical section and on again at end of it other interrupts? page faults peripheral device interrupts untrustworthy users! multi-processor systems? system call to inhibit other processes from execution? Kernel often switches interrupts off but only for a little time as possible

Operating Systems: Sync Shared variables Two cooperating processes, each of the form: while (TRUE) { entry section // each using the same shared critical section // variables in common exit section . . . . } Solution 1 ? shared variable : turn = 1; process 1 process 2 while (TRUE) { while (TRUE) { while (turn==2) { /* wait */ } while (turn==1) { /* wait */ } critical section 1 critical section 2 turn = 2; turn = 1; . . . . . . . . } }

Operating Systems: Sync Solution 2 ? shared variable c1 = 1, c2 = 1; process 1 process 2 while (TRUE) { while (TRUE) { while (c2==0) { /* wait */ } while (c1==0) { /* wait */ } c1 = 0; c2 = 0; critical section 1 critical section 2 c1 = 1; c2 = 1; . . . . . . . . } }

Operating Systems: Sync Solution 3 ? shared variable c1 = 1, c2 = 1; process 1 process 2 while (TRUE) { while (TRUE) { c1 = 0; c2 = 0; while (c2==0) { /* wait */ } while (c1==0) { /* wait */ } critical section 1 critical section 2 c1 = 1; c2 = 1; . . . . . . . . } }

Operating Systems: Sync Solution 4 ? shared variable c1 = 1, c2 = 1; process 1 process 2 while (TRUE) { while (TRUE) { while (TRUE) { while (TRUE) { c1 = 0; c2 = 0; if (c2==0) { if (c1==0) { c1 = 1; c2 = 1; continue; // to wait continue; // to wait } } break; break; } } critical section 1 critical section 2 c1 = 1; c2 = 1; . . . . . . . . } }

Operating Systems: Sync process 1 process 2

Operating Systems: Sync Solution 5 (Dekker) shared variable c1 = 1, c2 = 1, turn = 1; process 1 process 2 while (TRUE) { while (TRUE) { L1: c1 = 0; L2: c2 = 0; while (c2==0) { while (c1==0) { if (turn==1) continue; if (turn==2) continue; c1 = 1; c2 = 1; while (turn==2) { /* wait */ } while (turn==1) { /* wait */ } goto L1; goto L2; } } critical section 1 critical section 2 turn = 2; turn = 1; c1 = 1; c2 = 1; . . . . . . . . } }

Operating Systems: Sync process 1 process 2

Operating Systems: Sync Solution 6 (Peterson) shared variable c1 = 1, c2 = 1, turn = 1; process 1 process 2 while (TRUE) { while (TRUE) { c1 = 0; c2 = 0; turn = 2; turn = 1; while (c2==0 && turn==2) { while (c1==0 && turn==1) { // wait // wait } } critical section 1 critical section 2 c1 = 1; c2 = 1; . . . . . . . . } }

Operating Systems: Sync process 1 process 2

Verification of Peterson’s solution (due to E.W. Dijkstra) Operating Systems: Sync Verification of Peterson’s solution (due to E.W. Dijkstra) add line numbers shared variable c1 = 1, c2 = 1, turn = 1; process 1 process 2 while (TRUE) { while (TRUE) { <1> c1 = 0; c2 = 0; <2> turn = 2; turn = 1; <3> while (c2==0 && turn==2) { } while (c1==0 && turn==1) { } <4> critical section 1 critical section 2 <5> c1 = 1; c2 = 1; <6> . . . . . . . . } } notation : Pn@<m> : process n is executing line m let H1 = ((turn==2)  ((turn==1)  P2@<3>))  (c1==0) H2 = ((turn==1)  ((turn==2)  P1@<3>))  (c2==0)

Operating Systems: Sync For process 1, add assertions while (TRUE) { <1> c1 = 0; { P1@<1> } <2> turn = 2; { P1@<2>  (c1==0) } <3> while (c2==0 && turn==2) { } { P1@<3>  H1 } <4> critical section 1 { P1@<4>  H1 } <5> c1 = 1; <6> . . . . } P2 cannot falsify H1 : P2 cannot falsify (c1==0) when P2 falsifies (turn==2), it verifies (turn==1)  P2@<3> P2 cannot falsify (turn==1)  P2@<3>  (c1==0) because this is the loop condition of <3> P1 cannot falsify H2, similarly

Operating Systems: Sync Mutual exclusion is guaranteed because , in their critical sections: P1@<4>  H1  P2@<4>  H2  P1@<4>  P2@<4>  ((turn==2)  ((turn==1)  P2@<3>))  (c1==0)  ((turn==1)  ((turn==2)  P1@<3>))  (c2==0)  (turn==2)  (turn==1)  FALSE Progress is guaranteed because there is an indefinite delay if and only if: P1@<3>  P2@<3>  (turn==2)  (c2==0)  (turn==1)  (c1==0)  FALSE

Operating Systems: Sync Bounded waiting is guaranteed because: consider P1@<3>, waiting because P2 is in its critical section when P2 comes out of its critical section and loops, it sets c2 = 1 and turn = 1 if P2 tries to re-enter its critical section, it will find : (turn==1)  (c1==0), and be forced to wait meanwhile, P1 must eventually find its loop condition false (turn!=2) and can enter its critical section

Multiple-process solution : the ‘Bakery’ algorithm (Lamport) Operating Systems: Sync Multiple-process solution : the ‘Bakery’ algorithm (Lamport) each process is allocated a numbered token and is ‘served’ in order if two processes get same token number, the lower process number wins shared variable : choosing [0:n-1] = 0(n), number [0:n-1] = 0(n); // process i while (TRUE) { choosing [i] = 1; number [i] = 1 + max( number[0], number[1], . . . number[n-1] ); choosing [i] = 0; for (j=0; j<n; j++) { while ( choosing [j] == 1) { /* wait */ } while ( number [j] != 0) && ((number [j], j) < (number [i], i)) { /* wait */ } } // (a,b) < (c,d) means a<c or (a==c and b<d) critical section i number [i] = 0; . . . . } when Pi is in its critical section and Pk has chosen its number [k] != 0, then (number [i], i} < (number [k], k)