Transcript Synchronisation

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
1
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
2
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.
3
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
4
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 rechecks 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
5
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
6
Operating Systems: Sync
Shared circular buffer : buffer [ 0 : max-1 ]
max-1 0 1
max-2
2
put
get
count
7
Operating Systems: Sync
• Producer process:
while (TRUE) {
• Consumer process:
while (TRUE) {
prod_item = next to be generated;
while (count==0) {
....
// wait until count>0
while (count==max) {
}
// wait until count<max
}
cons_item = buffer[get];
}
get = (get+1)%max;
buffer[put] = prod_item;
count = count-1;
put = (put+1)%max;
process new item;
count = count+1;
....
}
8
Operating Systems: Sync
• Problem statements:
–
count = count+1;
and
count = count-1;
– not indivisible statements
– compile to:
load reg, count
add reg, #1
store reg, count
load reg, count
sub reg, #1
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?
9
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?
10
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
11
Operating Systems: Sync
Shared variables
• Two cooperating processes, each of the form:
while (TRUE) {
entry section
critical section
exit section
....
}
// each using the same shared
// variables in common
Solution 1 ?
shared variable : turn = 1;
process 1
process 2
while (TRUE) {
while (turn==2) { /* wait */ }
critical section 1
turn = 2;
....
}
while (TRUE) {
while (turn==1) { /* wait */ }
critical section 2
turn = 1;
....
}
12
Operating Systems: Sync
Solution 2 ?
shared variable c1 = 1, c2 = 1;
process 1
process 2
while (TRUE) {
while (c2==0) { /* wait */ }
c1 = 0;
critical section 1
c1 = 1;
....
}
while (TRUE) {
while (c1==0) { /* wait */ }
c2 = 0;
critical section 2
c2 = 1;
....
}
13
Operating Systems: Sync
Solution 3 ?
shared variable c1 = 1, c2 = 1;
process 1
process 2
while (TRUE) {
c1 = 0;
while (c2==0) { /* wait */ }
critical section 1
c1 = 1;
....
}
while (TRUE) {
c2 = 0;
while (c1==0) { /* wait */ }
critical section 2
c2 = 1;
....
}
14
Operating Systems: Sync
Solution 4 ?
shared variable c1 = 1, c2 = 1;
process 1
process 2
while (TRUE) {
while (TRUE) {
c1 = 0;
if (c2==0) {
c1 = 1;
continue; // to wait
}
break;
}
critical section 1
c1 = 1;
....
}
while (TRUE) {
while (TRUE) {
c2 = 0;
if (c1==0) {
c2 = 1;
continue; // to wait
}
break;
}
critical section 2
c2 = 1;
....
}
15
Operating Systems: Sync
process 1
process 2
16
Operating Systems: Sync
Solution 5 (Dekker)
shared variable c1 = 1, c2 = 1, turn = 1;
process 1
while (TRUE) {
L1: c1 = 0;
while (c2==0) {
if (turn==1) continue;
c1 = 1;
while (turn==2) { /* wait */ }
goto L1;
}
critical section 1
turn = 2;
c1 = 1;
....
}
process 2
while (TRUE) {
L2: c2 = 0;
while (c1==0) {
if (turn==2) continue;
c2 = 1;
while (turn==1) { /* wait */ }
goto L2;
}
critical section 2
turn = 1;
c2 = 1;
....
}
17
Operating Systems: Sync
process 1
process 2
18
Operating Systems: Sync
Solution 6 (Peterson)
shared variable c1 = 1, c2 = 1, turn = 1;
process 1
process 2
while (TRUE) {
c1 = 0;
turn = 2;
while (c2==0 && turn==2) {
// wait
}
critical section 1
c1 = 1;
....
}
while (TRUE) {
c2 = 0;
turn = 1;
while (c1==0 && turn==1) {
// wait
}
critical section 2
c2 = 1;
....
}
19
Operating Systems: Sync
process 1
process 2
20
Operating Systems: Sync
Verification of Peterson’s solution (due to E.W. Dijkstra)
– add line numbers
shared variable c1 = 1, c2 = 1, turn = 1;
<1>
<2>
<3>
<4>
<5>
<6>
process 1
process 2
while (TRUE) {
c1 = 0;
turn = 2;
while (c2==0 && turn==2) { }
critical section 1
c1 = 1;
....
}
while (TRUE) {
c2 = 0;
turn = 1;
while (c1==0 && turn==1) { }
critical section 2
c2 = 1;
....
}
– 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)
21
Operating Systems: Sync
• For process 1, add assertions
<1>
<2>
<3>
<4>
<5>
<6>
while (TRUE) {
c1 = 0;
turn = 2;
while (c2==0 && turn==2) { }
critical section 1
c1 = 1;
....
}
{ P1@<1> }
{ P1@<2>  (c1==0) }
{ P1@<3>  H1 }
{ P1@<4>  H1 }
• 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
22
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
23
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
24
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)
25