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 P1 Process P2

. .

in = getchar(); .

. in = getchar();

chout = chin; 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

• 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

• 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

Drawbacksprocesses must strictly alternate reducing the speed of executionif 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

sectionturn = 1; //grant the turn to the

// other processwhile (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 sectiondelay - 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:

create_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 > 0Only readers in action.

At each finished message count is decremented by 1.

Count < 0At least one writer is waiting. The controller clears the finished queue, incrementing count until it becomes 0.

Count = 0The pending writer is granted access. The controller waits to receive a finished message, before proceeding. Count is set to 100.