Operating Systems, 122

Practical Session 7 Synchronization, part 3

Monitors, classical sync. problems

1

Monitor

• Monitor – a synchronization primitive.• A monitor is a collection of procedures, variables and

data structures, grouped together.• Mutual Exclusion – only one process can be active

within a monitor at any given time.• Programming language construct!

The compiler of the language will know that monitors procedures are different than other procedures, and will treat them differently. That means that the compiler is in charge of the mutual exclusion implementation.

Java synchronized methods2

A quick recap

Condition variables• A way for processes to block when they can’t continue.• Despite its name, it is used to indicate an event and not as a

regular valued variable. A CV is not a counter!• Two operations: wait, signal.

Wait: causes the process to block, and allows entry of other threads to the monitor.Signal:More than just one alternative:

1. Hoare type monitors: The signaler yields the monitor to the released thread. Signal will be the last operation within the monitor, which wakes up waiting processes (waiting on the same variable). This is not true for Java.

2. Mesa type monitors: The signaling process is allowed to continue.

3

The Sleeping Barber

Write a solution to the sleeping barber problem using monitors and condition variables.

Reminder, the sleeping barber:1. The barber cuts peoples hair in his shop, which has 2 doors – entrance and

exit. When people are in his shop, he gives them a hair cut, one at a time. When none are in his shop, he sleeps on his chair.

2. When a customer arrives and finds the barber sleeping, he awakens him and sits in the barber’s chair to receive his haircut. After the cut is done, the barber sees the customer out through the exit door.

3. If the barber is busy when a customer arrives, the customer waits in one of the chairs in the shop. If all are occupied, he goes away.

4. After serving a customer the barber looks to see if any are waiting and if so proceeds to serve one of them. Otherwise, he sleeps again in his chair.

4

The Sleeping Barberbarbershop: monitor

waiting : integer := 0; % customers waiting for haircutcustomers : condition; % used by barber, wait for a customerbarber : condition; % used by customer, wait for barber

procedure seek-customer( ) % called by the barberbegin

if waiting==0 then WAIT (customers); % sleeps if no customers

cut-hair();waiting = waiting-1; % one less customer waitingSIGNAL (barber); % free a waiting customer

end seek-customer;

5

The Sleeping Barberprocedure get-haircut( ) % called by a customerbegin

% is there a free chair to sit and wait? % if no free chairs just go awayif waiting < chairs then {

waiting = waiting+1; % one more customer waitingSIGNAL (customers) % if the barber is asleepWAIT (barber); % wait for turn with the barber

}end get-haircut;

end barbershop; % End of monitor

6

Java and monitors – Exercise

Write a code snippet in Java which will enforce a FIFO waking order (i.e., create a class in Java that will allow a programmer fair synchronization)

7

Java and monitors – Solutionclass WaitObject {

boolean released = false; // this flag avoids race!!!

synchronized void doWait() { while (! released) { try {wait(); } catch (InterruptedException ie) {} // ignore it }}synchronized void doNotify(){if (! released){ released = true;notify();}}

}8

Java and monitors – Solutionclass CriticalSection { // critical section that preserves FIFO

private Vector _waiting; // wait listprivate boolean _busy; // someone in critical section

public CriticalSection() { // constructor_waiting = new Vector(); // create wait list_busy = false; // no one is in the CS now.

}public void enter() {

WaitObject my_lock = null;synchronized(this){

if (! _busy) { _busy = true;return;

}else {my_lock = new WaitObject(); // create my unique lock_waiting.add(my_lock); // add to waiting list

}}my_lock.doWait(); // wait on lock

} 9

Java and monitors – Solutionpublic synchronized void leave() {

if (_waiting.size() > 0) { // someone is waiting WaitObject o = (WaitObject)_waiting.elementAt(0);_waiting.removeElementAt(0);o.doNotify();

} else {_busy = false;

}}

}

10

Java and monitors – Discussion

Does this code guarantee a FIFO waking order which is equivalent to the order in which threads reached the critical section entrance?

public void enter() {WaitObject my_lock = null;synchronized(this){

…}my_lock.doWait();

}

It does, however, guarantee a waking order on those threads already sleeping.

What happens when multiple threads attempt to enter at the same time?

11

NO!

Hoare monitors, Moed A 2010Monitor ProducerConsumer 1. condition full, empty

2. integer count initially 03. procedure insert(item: integer)4. begin5. if count=N then wait(full)6. insert_item(item)7. count=count+18. if count > 0 then signal(empty)9. end10. procedure remove: integer11. begin12. if count=0 then wait(empty)13. remove=remove_item()14. count=count-115. if count < N then signal(full)16. end

end Monitor

12

Hoare monitors, Moed A 2010

Recall that a monitor is a Hoare typed monitor if the following conditions hold:1. Whenever a ‘signal’ is received by a thread t it is guaranteed

that thread t will be the next thread to enter the monitor2. ‘signal’ is the last action taken within the monitor and a

thread executing it will immediately release the monitor afterward

Consider the above implementation for the producer consumer problem with N items and prove or disprove the following claim:The above implementation is correct even if used with non Hoare typed monitor

13

Hoare monitors, Moed A 2010

The following scenario contradicts the above claim:Assume an N sized buffer, already full. Now, consider a producer p1 attempting to add a new item. Reaching line 5 p1 must wait for some consumer to remove an item before it may continue. Now, we introduce a consumer c1 which successfully executes the remove function – including line 15 (signal). However, unlike a regular Hoare typed monitor, instead of having p1 take control of the monitor a new producer p2 is added. The monitor is taken by p2 which executes the entire insert() function. Finally, p1 is granted CPU time and continues its run (line 6 to the end of the function).Result: an extra item is added to the already full buffer

14

The one-way tunnel problem

• One-way tunnel

• Allows any number of processes in the

same direction

• If there is traffic in the opposite direction –

have to wait

• A special case of readers/writers

15

The one way tunnel (exam 2004)The one way tunnel solution:

int count[2];Semaphore mutex=1, busy=1;Semaphore waiting[2]={1,1};

void arrive(int direction){ down(&waiting[direction]); down(&mutex); count[direction]+=1; if (count[direction]==1){

up(&mutex);down(&busy);

} elseup(&mutex);

up(&waiting[direction]);}

void leave(int direction){ down(&mutex);

count[direction]-=1; if (count[direction]==0){

up(&busy); }

up(&mutex);

The one way tunnel (exam 2004)

1. Add changes to the one way tunnel solution so that vehicles from direction “0” are always preferred. Vehicles from direction “1” will only enter the tunnel if no vehicles at “0” are waiting.

2. Add changes to the one way tunnel solution so that there will be no starvation. If vehicles are present on both “0” and “1” they will take alternate turns in entering the tunnel. When there are vehicles coming from only one direction, they can pass through with no limitations.

Notes: • you may only use integers and binary semaphores.• You may change the solution for a single direction at a time.

The one way tunnel (exam 2004)1.Code for direction 0:Semaphore new_mutex=1;

void arrive() {down(&waiting[0]);down(&mutex); count[0]++;if(count[0] == 1) {

up(&mutex);down(&new_mutex);down(&busy);up(&new_mutex);

{ elseup(&mutex);

up(waiting[0]);}

Code for direction 1:

void arrive(int direction) {down(waiting[1]);down(&new_mutex);down(&mutex);count[1]++;if(count[1] == 1) {

up(&mutex);up(waiting[1]);down(busy);

{ else {up(&mutex);up(waiting[1]);

{up(&new_mutex);

}

The one way tunnel (exam 2004)2.For both directions:

void arrive(int direction) {down(waiting[direction]);down(new_mutex);down(mutex);count[direction]++;if(count[direction] == 1) {

up(mutex);up(waiting[direction]);down(busy);

{ else {up(mutex);up(waiting[direction]);

{up(new_mutex);

}Assuming semaphore fairness (new_mutex)

void leave(int direction){ down(&mutex);

count[direction]-=1; if (count[direction]==0){

up(&busy); } up(&mutex);

One way, convoy (midterm 2008)In the following question you must implement a solution to the convoy problem using only semaphores (and regular variables). In this problem, each thread represent a vehicle. The vehicles must go through a one way tunnel, but unlike the tunnel problem, here vehicles may only cross the tunnel in groups of exactly 5 (all in the same direction). A group of another 5 vehicles (from the same or opposite direction) may cross the tunnel again, only after the previous group of 5 vehicles comes out of it. The general code structure is as follows:

Variable Declaration PrepareToCross(int direction) CROSS DoneWithCrossing(int direction)

One way, convoy (midterm 2008)Implement PrepareToCross() and DoneWithCrossing(). For your implementation you may only use semaphores (counting or binary) and regular variables. No busy-waiting is allowed.We say a thread is passing the tunnel if it completed its call to PrepareToCross and haven’t called DoneWithCrossing or if it is still in PrepareToCross but is no longer waiting on a semaphore, and when it will receive CPU time it may complete the procedure without waiting.Your implementation must satisfy the following conditions:

1. Mutual Exclusion – threads from different direction may never be in the tunnel at the same time.

2. Threads may only cross in groups of 5. When the first is leaving PrepareToCross, there are exactly 4 others which are passing the tunnel as well.

3. Progress – Whenever there are 5 (or more) threads from the same direction waiting to cross the tunnel, then eventually, they will.

One way, convoy (midterm 2008)We will use the following:

Counting Semaphore waitingToCross[]={5,5}Counting Semaphore barrier[]={0,0}Binary Semaphore busy=1Binary Semaphore mutex=1

int waitingCount[]={0,0}int passed=0

One way, convoy (midterm 2008)PrepareToCross(int i){ down(&waitingToCross[i]); down(&mutex); waitingCount[i]++; If (waitingCount[i]<5){

up(&mutex);down(&barrier[i]);

} else {waitingCount[i]=0;up(&mutex);down(&busy);for (int k=0; k<4; k++) up(&barrier[i]);

} up(&waitingToCross[i]);}

DoneWithCrossing(int i){ down(&mutex); passed++; if (passed==5){

passed=0;up(&busy);

} up(&mutex);}

A quick recap

• Message passing• Used on distributed systems (when there is no shared

memory).• Uses send(), and receive() system calls.• Introduces a new set of problems, such as

acknowledgments, sequencing, addressing, authentication, etc’…

24

Reader/Writer problem with MP

Write a solution to the reader/writer problem using Message Passing.

Assume the following:1. Three groups of processes: readers, writer, manager.2. Multiple readers may access the DB simultaneously.3. A writer needs exclusive access to the DB.4. Readers have preference.

25

Reader/Writer problem with MPReader:

while (true){SEND (manager, start_read);RECEIVE (manager, msg); % wait for confirmationread_db();SEND (manager, end_read);use_data();

}Writer:

while (true){generate_data();SEND (manager, start_write);RECEIVE (manager, msg); % wait for confirmationwrite_to_db();SEND (manager, end_write);

}

26

Reader/Writer problem with MPManager:

int readers_count=0; % number of readers accessing DBboolean writing=false; % writing flagMessage msg;Queue readQ, writeQ; % Queues for waiting readers and writersProcessID src; % pid while (true){

src = RECEIVE(msg);switch msg.type{case (start_read):if (not writing){send(src, ok);readers_count++;} elsereadQ.add(src);

27

Reader/Writer problem with MPcase (end_read):

readers_count--;if (readers_count==0 && not writeQ.empty){

src=writeQ.remove;SEND (src, ok);writing = true;

}case (start_write):

if (readers_count==0 && not writing){SEND (src, ok);writing = true;

} elsewriteQ.add(src);

28

Reader/Writer problem with MPcase (end_write):

writing = false;if (readQ.empty && not writeQ.empty){

src = writeQ.remove;SEND(src, ok);writing = true;

} else {while (not readQ.empty){

src = readQ.remove;send(src, ok);readers_count++;

}}

} % switch} % while

29

The sleeping barber problem

• Barber shop - one service provider; many customers

• A finite waiting queue

• One customer is served at a time

• Service provider, barber, sleeps when no customers are waiting

• Customer leaves if shop is full

• Customer sleeps while waiting in queue

30

The sleeping barber#define CHAIRS 5semaphore customers = 0; // number of waiting customersSemaphore barbers = 0; // number of available barbers: either 0 or 1Semaphore mutex = 1; // mutex for accessing ‘waiting’Semaphore synch = 0; // synchronizing the service operationint waiting = 0; // copy of customers for reading

void barber(void) {while(TRUE) { down(customers); // block if no customers down(mutex); // access to ‘waiting’ waiting = waiting - 1; up(barbers); // barber is in.. up(mutex); // release ‘waiting’ cut_hair(); down(synch) //wait for customer to leave }

}

31

The sleeping barbervoid customer(void) {

down(mutex); // access to `waiting’ if(waiting < CHAIRS) { waiting = waiting + 1; // increment waiting up(customers); // wake up barber up(mutex); // release ‘waiting’ down(barbers); // go to sleep if barbers=0 get_haircut();

up(sync); //synchronize service } else { up(mutex); /* shop full .. leave */}

}

32