Concurrency: Mutual Exclusion and Synchronization Chapter 5

Concurrency Characteristics of concurrent / interleaved processes: share/compete for resources communicate synchronize their activities

Concurrency Same problems in multiprogramming and multiprocessing Basic method to support concurrency –mutual exclusion: the ability to exclude all other processes from a course of action while one process is engaged in that action

A Simple Example void echo() { chin = getchar(); chout = chin; putchar(chout); }

‘one processor’ case The echo procedure and its variables are shared by two processes P1 and P2 P1: chin = getchar(); // user types ‘x’ interrupted, chin contains ‘x’ P2: chin = getchar(); // user types ‘y’ chout = chin; putchar(chout); // ‘y’ is displayed interrupted, chin contains ‘y’ P1: chout = chin; putchar(chout); // ‘y’ is displayed instead of ‘x’

‘two-processors’ case Process P1Process P2. in = getchar();.. in = getchar(); chout = chin; putchar(chout);.. putchar(chout);.

Operating System Concerns Keep track of active processes Allocate and deallocate resources –Processor time –Memory –Files –I/O devices Protect data and resources Result of process must be independent of the speed of execution of other concurrent processes

Process Interaction Processes unaware of each other –Independent –competition for resources Processes indirectly aware of each other –share access to some object –cooperation –data coherence problem Process directly aware of each other –work jointly on some activity –communicate via messages to coordinate activities –cooperation

Control problems Mutual exclusion Two processes require access to a single non-shareable resource. Critical resource - the resource in question. Critical section in the program - the portion in the program that uses the resource The rule: only one program at a time be allowed in its critical section

Deadlock Involves at least two processes P1 waits for an event to be produced by P2 P2 waits for an event to be produced by P1

Starvation Involves at least three processes P1, P2, P3, competing for non-shareable resource P1 and P2 alternatively use the resource P3 may indefinitely be denied access to that resource.

Competition Among Processes for Resources Mutual Exclusion –Critical sections Only one program at a time is allowed in its critical section Example only one process at a time is allowed to send command to the printer Deadlock Starvation

Cooperation Among Processes by Sharing Writing must be mutually exclusive Critical sections are used to provide data integrity

Cooperation Among Processes by Communication Messages –Mutual exclusion is not a control requirement Possible to have deadlock –Each process waiting for a message from the other process Possible to have starvation –Two processes sending message to each other while another process waits for a message

Requirements for Mutual Exclusion Only one process at a time is allowed in the critical section for a resource A process that halts in its non-critical section must do so without interfering with other processes No deadlock or starvation Grant access to a critical section when there is no other process using it No assumptions are made about relative process speeds or number of processes A process remains inside its critical section for a finite time only

Mutual Exclusion - software approaches First attempt Processes P0 and P1, global variable turn If turn = 0, P0 can enter its critical section If turn = 1, P1 can enter its critical section while (turn != 0) /* do nothing */ ; /* critical section */; turn = 1;

First attempt Each process enters its critical section and then transfers the access (by changing the value of turn) to the other process.  busy waiting- while waiting to enter the critical section the process repeatedly checks the status of its permission (reads the value of turn)  guarantees mutual exclusion Drawbacks processes must strictly alternate reducing the speed of execution if one process fails the other is permanently blocked.

Second attempt Using a separate variable for each process whose contents determine whether a process is in use of its critical section or not while (flag[1]) /* do nothing */ ; flag[0] = true; /* critical section */; flag[0] = false; No mutual exclusion however, due to the possibility of interleaving the operations for status checking and status changing

Third Attempt Set flag to enter critical section before checking other processes flag[0] = true; while (flag[1]) /* do nothing */ ; /* critical section */; flag[0] = false;

Third Attempt If another process is in the critical section when the flag is set, the process is blocked until the other process releases the critical section Deadlock is possible when two process set their flags to enter the critical section. Now each process must wait for the other process to release the critical section

Fourth Attempt A process sets its flag to indicate its desire to enter its critical section but is prepared to reset the flag flag[0] = true; while (flag[1]) { flag[0] = false; /* delay */ ; flag[0] = true; } /* critical section */; flag[0] = false;.

Fourth Attempt This is not working due to the possibility of interleaving the operations for status changing and status checking. There is a situation when none of the processes would be able to enter its critical section, similar to the situations described above.

Correct Solution Each process gets a turn at the critical section If a process wants the critical section, it sets its flag and may have to wait for its turn

Dekker’s algorithm flag[0] = true;//indicate the need to enter // critical section while (flag[1])//while the other process is // also entering if (turn == 1)// if it is its turn { flag[0] = false; //reset the flag to false while (turn == 1) // wait while it is still // its turn /* do nothing */ ; flag[0] = true; //indicate entering the // critical section } /* critical section */; turn = 1;//give the turn to the other process flag [0] = false; //change status

Peterson’s algorithm flag[0] = true;//indicate the need to // enter critical section turn = 1;//grant the turn to the // other process while (flag[1] && turn == 1) //mutual exclusion /* do nothing */ /* critical section */; flag [0] = false;//change status

Mutual Exclusion: Hardware Support Interrupt Disabling –Disabling interrupts guarantees mutual exclusion –Processor is limited in its ability to interleave programs –Multiprocessing disabling interrupts on one processor will not guarantee mutual exclusion

Mutual Exclusion: Hardware Support Special Machine Instructions Performed in a single instruction cycle Not subject to interference from other instructions –Reading and writing –Reading and testing

Mutual Exclusion Machine Instructions Advantages –Applicable to any number of processes on either a single processor or multiple processors sharing main memory –It is simple and therefore easy to verify –It can be used to support multiple critical sections

Mutual Exclusion Machine Instructions Disadvantages –Busy-waiting consumes processor time –Starvation is possible when a process leaves a critical section and more than one process is waiting. –Deadlock If a low priority process has the critical region and a higher priority process needs, the higher priority process will obtain the processor to wait for the critical region

Semaphores The setting: Special variable called a semaphore is used for signaling If a process is waiting for a signal, it is suspended until that signal is sent Wait and signal operations cannot be interrupted Queue is used to hold processes waiting on the semaphore

Semaphores Semaphore is a variable that has an integer value –May be initialized to a nonnegative number –Wait operation decrements the semaphore value –Signal operation increments semaphore value

Semaphore types Binary semaphore - binary values 0 and 1. Strong semaphore - a semaphore whose definition includes the policy of first-in-first-out (FIFO) queue. Weak semaphore - a semaphore that does not specify the order in which processes are removed from the queue. Strong semaphores guarantee avoiding starvation.

Example: Barbershop Problem

Mutual exclusion with semaphores Each process performs: wait(s); /* critical section */ signal(s);

Producer/Consumer Problem One or more producers are generating data and placing these in a buffer A single consumer is taking items out of the buffer one at time Only one producer or consumer may access the buffer at any one time

Producer/Consumer Problem Infinite Buffer

Circular Buffer

Producer producer: while (true) { /* produce item v */ b[in] = v; in++; }

Consumer consumer: while (true) { while (in <= out) /*do nothing */; w = b[out]; out++; /* consume item w */ }

Producer/Consumer Problem the consumer takes an item only if one is available –a semaphore that prevents the consumer from reading when the buffer is empty (n = out - in) mutual exclusion is not ensured solution: –a semaphore that allows only one producer/consumer to perform write/read

Producer/Consumer Problem s - semaphore for entering the critical section delay - semaphore to ensure reading from non-empty buffer Producer:Consumer: produce();wait(delay); wait (s);wait(s); append();take(); signal(delay);signal(s); signal(s);consume();

Monitors Monitor is a software module Chief characteristics –Local data variables are accessible only by the monitor –Process enters monitor by invoking one of its procedures –Only one process may be executing in the monitor at a time

Monitors synchronization - condition variables contained within the monitor and accessible only from within the monitor. –cwait(c) –csignal(c) The advantage that monitors have over semaphores is that all of the synchronization functions are confined to the monitor.

Monitors  cwait(c): Suspend execution of the calling process on condition c. The monitor is now available for use by another process.  csignal(c): Resume execution of some process suspended after a cwait on the same condition. If there are several such processes, choose one of them; if there is no such process, do nothing.

Message Passing Enforce mutual exclusion Exchange information send (destination, message) receive (source, message)

Synchronization Sender and receiver may or may not be blocking (waiting for message) Blocking send, blocking receive –Both sender and receiver are blocked until message is delivered –Called a rendezvous

Synchronization Nonblocking send, blocking receive –Sender continues processing such as sending messages as quickly as possible –Receiver is blocked until the requested message arrives Nonblocking send, nonblocking receive –Neither party is required to wait

Addressing Direct addressing –send primitive includes a specific identifier of the destination process –receive primitive could know ahead of time which process a message is expected –receive primitive could use source parameter to return a value when the receive operation has been performed

Addressing Indirect addressing –messages are sent to a shared data structure consisting of queues –queues are called mailboxes –one process sends a message to the mailbox and the other process picks up the message from the mailbox

Message Format

Queuing Discipline First-in-first-out Specifying message priority Allow receiver to inspect message queue and select which message to receive next.

Mutual exclusion via messages Process: receive(mutex, msg); /* critical section */ send(mutex, msg); Main program: c reate_mailbox(mutex); send(mutex,null); parbegin(P(1),…);

Readers/Writers Problem Any number of readers may simultaneously read the file Only one writer at a time may write to the file If a writer is writing to the file, no reader may read it

Readers have priority Since the reading is not mutually exclusive, if someone is reading, any other can join the reading. Writers are potentially subjected to starvation. Semaphore: wsem - guarantees only one writer and mutually excludes reading and writing.

Readers have priority The algorithm: Only the first reader and each writer wait on wsem. The last reader and each writer signal wsem. Readers count their number in a variable readcount. To prevent simultaneous updating, they use a semaphore x

Initially wsem and x are set to 1, readcount is 0. /* program readerswriters */ int readcount; semaphore x = 1, wsem = 1; /* main */ void main(); { readcount = 0; parbegin (reader, writer); }

/* readers */ wait(x); readcount++; if (readcount == 1) wait (wsem); signal(x); READUNIT(); wait(x); readcount--; if (readcount == 0) signal(wsem); signal(x); /* writers */ wait(wsem); WRITEUNIT(); signal(wsem);

Writers have priority The first writer that comes blocks the subsequent readers from joining the reading pool until all writers finish their job. rsem - to prevent subsequent readers from joining the reading pool. It is set by the first writer, and released by the last writer y - to prevent simultaneous updating of writecount z - to queue the subsequent readers

/* program readerswriters */ int readcount; semaphore x = 1, y = 1, z = 1, wsem = 1, rsem = 1; /* main */ void main(); { readcount = writecount = 0; parbegin (reader, writer); }

/* readers */ wait(z); wait(rsem); wait(x); readcount++; if (readcount == 1) wait (wsem); signal(x); signal(rsem); signal(z); READUNIT(); wait(x); readcount--; if (readcount == 0) signal(wsem); signal(x); /* writers */ wait(y); writecount++; if (writecount == 1) wait (rsem); signal(y); wait(wsem); WRITEUNIT(); signal(wsem); wait(y); writecount--; if (writecount == 0) signal(rsem); signal(y);

Alternative solution with messages The basic idea: Send message to request access Receive message that grants the access Do the jib Send message to indicate finished job.

Controller process readrequest queue writerequest queue finished queue a variable count is used for scheduling. Writers have priority

count Count > 0 Only readers in action. At each finished message count is decremented by 1. Count < 0 At least one writer is waiting. The controller clears the finished queue, incrementing count until it becomes 0. Count = 0 The pending writer is granted access. The controller waits to receive a finished message, before proceeding. Count is set to 100.