Chapter 6: Synchronization

Tools

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne

 Outline
 Background
 The Critical-Section Problem
 Peterson’s Solution
 Hardware Support for Synchronization
 Mutex Locks
 Semaphores
 Monitors
 Liveness
 Evaluation

Operating System Concepts – 10th Edition 6.2 Silberschatz, Galvin and Gagne
 Objectives
 Describe the critical-section problem and
illustrate a race condition
 Illustrate hardware solutions to the
critical-section problem using memory
barriers, compare-and-swap operations,
and atomic variables
 Demonstrate how mutex locks,
semaphores, monitors, and condition
variables can be used to solve the critical
section problem
 Evaluate tools that solve the critical-
section problem in low-, Moderate-, and
high-contention scenarios

Operating System Concepts – 10th Edition 6.3 Silberschatz, Galvin and Gagne
 Background
 Processes can execute concurrently
• May be interrupted at any time, partially
completing execution
 Concurrent access to shared data may result in data
inconsistency
 Maintaining data consistency requires mechanisms
to ensure the orderly execution of cooperating
processes
 We illustrated in chapter 4 the problem when we
considered the Bounded Buffer problem with use of a
counter that is updated concurrently by the producer
and consumer, which lead to race condition

Operating System Concepts – 10th Edition 6.4 Silberschatz, Galvin and Gagne
 Race Condition - Producer and Consumer
 Producer Process Code:
while (true) {while (count == BUFFER SIZE); /* do
nothing */
buffer[in] = next produced;
in = (in + 1) % BUFFER SIZE;
count++; }
 Consumer Process Code:
while (true) {while (count == 0); /* do nothing */
next consumed = buffer[out];
out = (out + 1) % BUFFER SIZE;
count--; }
 Race Condition:
Let’s assume count==5
If both processes concurrently execute without
cooperation, the next value of count could be any 4, 5,
or 6

Operating System Concepts – 10th Edition 6.5 Silberschatz, Galvin and Gagne
 Race Condition - Producer and Consumer …Cont
 Assembly Language Equivalent Code for count++
register1 = count
register1 = register1 + 1
count = register1
 Assembly Language Equivalent Code for count--
register2 = count
register2 = register2 − 1
count = register2
 Without Cooperation, both codes may run as following:
T0: producer execute register1 = count {register1 =
5}
T1: producer execute register1 = register1 +1
{register1 = 6}
T2: consumer execute register2 = count {register2 =
5}
T3: consumer execute register2 = register2 −1
{register2 = 4}
T4: producer execute6.6count = register1 {count
Operating System Concepts – 10th Edition Silberschatz,= 6} and Gagne
Galvin
 Race Condition - Producer and Consumer …Cont
 Assembly Language Equivalent Code for count++
register1 = count
register1 = register1 + 1
count = register1
 Assembly Language Equivalent Code for count--
register2 = count
register2 = register2 − 1
count = register2
 Without Cooperation, both codes may run as following:
T0: producer execute register1 = count {register1 =
5}
T1: producer execute register1 = register1 +1
{register1 = 6}
T2: consumer execute register2 = count {register2 =
5}
T3: consumer execute register2 = register2 −1
{register2 = 4}
T4:consumer execute
Operating System Concepts – 10th Edition 6.7count = register2 Silberschatz,
{count = 4} and Gagne
Galvin
 Race Condition - Solution

 We need to ensure that only one process at a time can

be manipulating the variable count

 A situation like this, where several processes access and

manipulate same data concurrently and the outcome of
the execution depends on the specific order in which the
access takes place, is called a Race Condition and such
processes are called Cooperating Processes

 Operating Systems address race condition problem

through Process Synchronization and Coordination among
Cooperating Processes

Operating System Concepts – 10th Edition 6.8 Silberschatz, Galvin and Gagne
 Critical Section Problem
 Consider system of n processes {p0, p1, … pn-1}
 Each process has Critical Section segment of code
• Process may be changing common variables, updating
table, writing file, etc.
• When one process is in its Critical Section, no other
may be in its critical section
 Critical Section problem is solved by designing a protocol
that the processes can use to synchronize their activity to
cooperatively share data
 Each process must ask permission to enter its Critical
Section
• The section of code implementing this request is the
Entry Section
• Followed by the Critical Section code and then by the
• Exit Section code, and finally by the
• Remainder Section code
Operating System Concepts – 10th Edition 6.9 Silberschatz, Galvin and Gagne
 Critical Section

 General structure of process Pi

Operating System Concepts – 10th Edition 6.10 Silberschatz, Galvin and Gagne
 Critical-Section Problem (Cont.)
Requirements for solution to critical-section problem

1. Mutual Exclusion - If process Pi is executing in its critical

section, then no other processes can be executing in
their critical sections
2. Progress - If no process is executing in its critical section
and there exist few processes that wish to enter their
critical section, then the selection of the process that
will enter the critical section next cannot be postponed
indefinitely
3. Bounded Waiting – An upper bound must exist on the
number of times that other processes may be allowed to
enter their critical sections after a process has made a
request to enter its critical section and before that
request is granted
• Assume that each process executes at a nonzero
speed
• No assumption concerning relative speed of the n
processes 6.11 Silberschatz, Galvin and Gagne
Operating System Concepts – 10th Edition
 Another Race Condition Example
 Processes P0 and P1 are creating child processes using
the fork() system call
 Race condition on kernel variable next_available_pid
which represents the next available process identifier
(pid)

 Unless there is a mechanism to prevent P0 and P1 from

accessing the variable next_available_pid the same
pid could be assigned to two different processes!

Operating System Concepts – 10th Edition 6.12 Silberschatz, Galvin and Gagne
 Interrupt-based Solution
 Entry section: disable interrupts
 Exit section: enable interrupts
 Will this solve the problem?
• What if the critical section is code that runs for an hour?
• Can some processes starve – never enter their critical section?
• What if there are two
CPUs?

Operating System Concepts – 10th Edition 6.13 Silberschatz, Galvin and Gagne
 Software Solution 1

 Two Process Solution

 Assume that the load and store machine-
language instructions are atomic; that is, cannot
be interrupted
 The two processes share one variable:
• int turn;
 The variable turn indicates whose turn it is to
enter the critical section

Operating System Concepts – 10th Edition 6.14 Silberschatz, Galvin and Gagne
 Algorithm for Process Pi

while (true){

turn = i;
while (turn= =j); /*Continue running this until turn!-J*/

/* critical section */

turn = j;

/* remainder section */

Operating System Concepts – 10th Edition 6.15 Silberschatz, Galvin and Gagne
 Algorithm for Process Pj

while (true){

turn = j;
while (turn= =i); /*Continue running this until turn!-i*/

/* critical section */

turn = i;

/* remainder section */

Operating System Concepts – 10th Edition 6.16 Silberschatz, Galvin and Gagne
 Correctness of the Software Solution

 Mutual exclusion is preserved

Pi enters critical section only if
turn = i
and turn cannot be both 0 and 1 at the same time
 What about the Progress requirement?
 What about the Bounded-Waiting requirement?

Operating System Concepts – 10th Edition 6.17 Silberschatz, Galvin and Gagne
 Peterson’s Solution
 Assumes only two process on a single processor
system
 Assume that the load and store machine-
language instructions are atomic; that is, cannot
be interrupted
 The two processes share two variables:
• int turn;
• boolean flag[2]
 The variable turn indicates whose turn it is to
enter the critical section
 The flag array is used to indicate if a process is
ready to enter the critical section.
• flag[i] = true implies that process Pi is
ready!

Operating System Concepts – 10th Edition 6.18 Silberschatz, Galvin and Gagne
 Algorithm for Process Pi

while (true){

flag[i] = true;
turn = j;
while (flag[j] && turn = = j);

/* critical section */

flag[i] = false;

/* remainder section */

Operating System Concepts – 10th Edition 6.19 Silberschatz, Galvin and Gagne
 Algorithm for Process Pj

while (true){

flag[j] = true;
turn = i;
while (flag[i] && turn = = i);

/* critical section */

flag[j] = false;

/* remainder section */

Operating System Concepts – 10th Edition 6.20 Silberschatz, Galvin and Gagne
 Correctness of Peterson’s Solution

 Provable that the three Critical Section requirements

are met:
1. Mutual exclusion is preserved
Pi enters its Critical Section only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met

Operating System Concepts – 10th Edition 6.21 Silberschatz, Galvin and Gagne
 Peterson’s Solution and Modern Architecture

 Although useful for demonstrating an algorithm,

Peterson’s Solution is not guaranteed to work on
modern architectures
• To improve performance, processors and/or
compilers may reorder operations that have no
dependencies
 Understanding why it will not work is useful for
better understanding race conditions
 For single-threaded this is ok as the result will always
be the same
 For multithreaded the reordering may produce
inconsistent or unexpected results!

Operating System Concepts – 10th Edition 6.22 Silberschatz, Galvin and Gagne
 Peterson’s Solution Revisited

 The effects of instruction reordering in Peterson’s

Solution

 This allows both processes to be in their critical section

at the same time!
 To ensure that Peterson’s solution will work correctly on
modern computer architecture we must use Memory
Barrier.

Operating System Concepts – 10th Edition 6.23 Silberschatz, Galvin and Gagne
 Modern Architecture Example

 Two threads share the data:

boolean flag = false;
int x = 0;
 Thread 1 performs
while (!flag);
print x
 Thread 2 performs
x = 100;
flag = true
 What is the expected output?

100

Operating System Concepts – 10th Edition 6.24 Silberschatz, Galvin and Gagne
 Modern Architecture Example (Cont.)

 However, since the variables flag and x are

independent of each other, the instructions:

flag = true;
x = 100;

for Thread 2 may be reordered

 If this occurs, the output may be 0!

Operating System Concepts – 10th Edition 6.25 Silberschatz, Galvin and Gagne
 Synchronization Hardware
 Many systems provide hardware support for
implementing the critical section code.
 Uniprocessors – could disable interrupts
• Currently running code would execute without
preemption
• Generally too inefficient on multiprocessor systems
 Operating systems using this not broadly
scalable
 We will look at three forms of hardware support:
1. Memory Barriers
2. Hardware Instructions
3. Atomic Variables

Operating System Concepts – 10th Edition 6.26 Silberschatz, Galvin and Gagne
 Memory Barrier

 Memory Model guarantees the memory a computer

architecture makes to application programs
 Memory models may be either:
• Strongly Ordered – where a memory modification
of one processor is immediately visible to all
other processors
• Weakly Ordered – where a memory modification
of one processor may not be immediately visible
to all other processors
 A Memory Barrier is an instruction that forces any
change in memory to be propagated (made visible)
to all other processors

Operating System Concepts – 10th Edition 6.27 Silberschatz, Galvin and Gagne
 Memory Barrier Instructions

memory_barrier();.
 When a memory barrier instruction is performed, the
system ensures that all loads and stores are
completed before any further load or store
operations are performed
 Therefore, even if instructions were reordered, the
memory barrier ensures that the store operations
are completed in memory and visible to other
processors before future load or store operations
are performed

Operating System Concepts – 10th Edition 6.28 Silberschatz, Galvin and Gagne
 Memory Barrier Example
 Returning to the previous example
 We could add a memory barrier to the following
instructions to ensure Thread 1 outputs 100:
 Thread 1 now performs
while (!flag)
memory_barrier();
print x
 Thread 2 now performs
x = 100;
memory_barrier();
flag = true
 For Thread 1 we are guaranteed that that the
value of flag is loaded before the value of x
 For Thread 2 we ensure that the assignment to x
occurs before the assignment flag

Operating System Concepts – 10th Edition 6.29 Silberschatz, Galvin and Gagne
 Hardware Instructions
 Atomic Operation
• A function or action implemented as a sequence
of one or more instructions that appears to be
indivisible; that is, no other process can see an
intermediate state or interrupt the operation. The
sequence of instruction is guaranteed to execute
as a group, or not execute at all, having no visible
effect on system state. Atomicity guarantees
isolation from concurrent processes.
 Special hardware instructions that allow us to either
test-and-modify the content of a word or swap the
contents of two words atomically (uninterruptedly.)
• Test-and-Set instruction
• Compare-and-Swap instruction

Operating System Concepts – 10th Edition 6.30 Silberschatz, Galvin and Gagne
 The test_and_set Instruction

 Definition
boolean test_and_set (boolean
*target)
{
boolean rv = *target;
*target = true;
return rv:
}
 Properties
• Executed atomically
• Returns the original value of passed
parameter
• Set the new value of passed parameter to
true

Operating System Concepts – 10th Edition 6.31 Silberschatz, Galvin and Gagne
 Solution using test_and_set()
 Shared boolean variable lock, initialized to false
 Solution:
do {
while (test_and_set(&lock))
; /* do nothing */

/* critical section */

lock = false;
/* remainder section */
} while (true);

 Does it solve the critical-section problem?

Operating System Concepts – 10th Edition 6.32 Silberschatz, Galvin and Gagne
 The compare_and_swap Instruction
 Definition
int compare_and_swap(int *value, int expected, int new_value)
{
int temp = *value;
if (*value == expected)
*value = new_value;
return temp;
}
 Properties
• Executed atomically
• Returns the original value of passed parameter value
• Set the variable value the value of the passed
parameter new_value but only if *value == expected is
true. That is, the swap takes place only under this
condition

Operating System Concepts – 10th Edition 6.33 Silberschatz, Galvin and Gagne
 Solution using compare_and_swap
 Shared integer lock initialized to 0;
 Solution:
while (true){
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */

/* critical section */

lock = 0;

/* remainder section */
}

 While it solves the critical-section problem

 Bounded-waiting requirement is NOT Solved

Operating System Concepts – 10th Edition 6.34 Silberschatz, Galvin and Gagne
 Bounded-waiting with compare-and-swap

while (true) {
waiting[i] = true;
key = 1;
while (waiting[i] && key == 1)
key = compare_and_swap(&lock,0,1);
waiting[i] = false;
/* critical section */
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = 0;
else
waiting[j] = false;
/* remainder section */
}

Operating System Concepts – 10th Edition 6.35 Silberschatz, Galvin and Gagne
 Atomic Variables

 Typically, instructions such as compare-and-

swap are used as building blocks for other
synchronization tools.
 One tool is an atomic variable that provides
atomic (uninterruptible) updates on basic data
types such as integers and booleans
 For example:
• Let sequence be an atomic variable
• Let increment() be operation on the atomic
variable sequence
• The Command:
increment(&sequence);
ensures sequence is incremented without
interruption

Operating System Concepts – 10th Edition 6.36 Silberschatz, Galvin and Gagne
 Atomic Variables

 The increment() function can be implemented as follows:

void increment(atomic_int *v)

{
int temp;
do {
temp = *v;
}
while (temp != (compare_and_swap(v,temp,temp+1));
}

Operating System Concepts – 10th Edition 6.37 Silberschatz, Galvin and Gagne
 Mutex Locks
 Previous solutions are complicated and generally
inaccessible to application programmers
 OS designers build software tools to solve critical
section problem
 Simplest is mutex lock
• Boolean variable indicating if lock is available or not
 Protect a critical section by
• First acquire() a lock
• Then release() the lock
 Calls to acquire() and release() must be atomic
• Usually implemented via hardware atomic
instructions such as compare-and-swap
 But this solution requires busy waiting
• This lock therefore called a spinlock

Operating System Concepts – 10th Edition 6.38 Silberschatz, Galvin and Gagne
 Solution to CS Problem Using Mutex Locks

while (true) {
acquire lock

critical section

release lock

remainder section
}

Operating System Concepts – 10th Edition 6.39 Silberschatz, Galvin and Gagne
 Semaphore

 Synchronization tool that provides more

sophisticated ways (than Mutex locks) for
processes to synchronize their activities.
 Semaphore S – integer variable
 Can only be accessed via two indivisible (atomic)
operations
• wait() and signal()
 Originally called P() and V()
 Definition of the wait() operation
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
 Definition of the signal() operation
signal(S) {
S++;
}

Operating System Concepts – 10th Edition 6.40 Silberschatz, Galvin and Gagne
 Semaphore (Cont.)
 Counting semaphore – integer value can range
over an unrestricted domain
 Binary semaphore – integer value can range
only between 0 and 1
• Similar as a mutex lock
 Can implement a counting semaphore S as a
binary semaphore
 With semaphores we can solve various
synchronization problems

Operating System Concepts – 10th Edition 6.41 Silberschatz, Galvin and Gagne
 Semaphore Usage Example
 Solution to the CS Problem
• Create a semaphore “mutex” initialized to 1
wait(mutex);
CS
signal(mutex);
 Consider P1 and P2 that with two statements S1
and S2 and the requirement that S1 to happen
before S2
• Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;

Operating System Concepts – 10th Edition 6.42 Silberschatz, Galvin and Gagne
 Semaphore Implementation
 Must guarantee that no two processes can execute
the wait() and signal() on the same semaphore at
the same time
 Thus, the implementation becomes the critical
section problem where the wait and signal code are
placed in the critical section
 Could now have busy waiting in critical section
implementation
• But implementation code is short
• Little busy waiting if critical section rarely
occupied
 Note that applications may spend lots of time in
critical sections and therefore this is not a good
solution

Operating System Concepts – 10th Edition 6.43 Silberschatz, Galvin and Gagne
 Semaphore Implementation with no Busy waiting

 With each semaphore there is an associated

waiting queue
 Each entry in a waiting queue has two data items:
• Value (of type integer)
• Pointer to next record in the list
 Two operations:
• block – place the process invoking the operation
on the appropriate waiting queue
• wakeup – remove one of processes in the waiting
queue and place it in the ready queue

Operating System Concepts – 10th Edition 6.44 Silberschatz, Galvin and Gagne
 Implementation with no Busy waiting (Cont.)

 Waiting queue
typedef struct {
int value;
struct process *list;
} semaphore;

Operating System Concepts – 10th Edition 6.45 Silberschatz, Galvin and Gagne
 Implementation with no Busy waiting (Cont.)

wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}

Operating System Concepts – 10th Edition 6.46 Silberschatz, Galvin and Gagne
 Classic Problems of Synchronization

 The Bounded-Buffer Problem

 The Readers–Writers Problem

 The Dining-Philosophers Problem

Operating System Concepts – 10th Edition 6.47 Silberschatz, Galvin and Gagne
 The Bounded-Buffer Problem

Producer Process Consumer Process

do { do {
// produce an item in wait(full);
nextp wait(mutex);
wait(empty); // remove an item from
wait(mutex); buffer to nextc
// add nextp to buffer signal(mutex);
signal(mutex); signal(empty);
signal(full); // consume the item in
} while (TRUE); nextc
} while (TRUE);

Operating System Concepts – 10th Edition 6.48 Silberschatz, Galvin and Gagne
 The Readers–Writers Problem
Writer Process Reader Process
do {
do { wait(mutex);
wait(wrt); readcount++;
// writing is performed if (readcount == 1)
signal(wrt); wait(wrt);
} while (TRUE); signal(mutex);
// reading is performed
wait(mutex);
readcount--;
if (readcount == 0)
signal(wrt);
signal(mutex);
} while (TRUE);

Operating System Concepts – 10th Edition 6.49 Silberschatz, Galvin and Gagne
 The Dining-Philosophers Problem
States
• Thinking
• Hungary
(Picking 2 Chopsticks)
• Eating
Semaphore Chopstick[5];
do {
wait(chopstick[i]);
wait(chopstick[(i+1) % 5]);
// eat
signal(chopstick[i]);
signal(chopstick[(i+1) % 5]);
// think
} while (TRUE);

Operating System Concepts – 10th Edition 6.50 Silberschatz, Galvin and Gagne
 The Dining-Philosophers Solution
• Allow at most 4 philosophers to be simultaneously
sitting at the table
• Allow a philosopher to pick up chopsticks only if
both chopsticks are available
 Pick both chopsticks in a Critical Section

• Use an Asymmetric Solution:

 An odd philosopher first picks up left chopstick and then
right chopstick, whereas an even philosopher first picks up
right chopstick followed by left chopstick

Operating System Concepts – 10th Edition 6.51 Silberschatz, Galvin and Gagne
 Problems with Semaphores

 Incorrect use of semaphore operations:

• signal(mutex) …. wait(mutex)

• wait(mutex) … wait(mutex)

• Omitting of wait (mutex) and/or signal

(mutex)

 These – and others – are examples of what can

occur when semaphores and other synchronization
tools are used incorrectly.

Operating System Concepts – 10th Edition 6.52 Silberschatz, Galvin and Gagne
 ANOTHER EXPLANATION
OF MONITORS

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne

 Monitors
• A programming language construct to control access to
shared variables
– Locking code usually added by compiler; enforced at runtime
• A monitor is a software module consisting of:
– Shared variables
– Functions that operate on the shared variables
– Support for synchronized access to these functions
• Monitors protect data from unstructured access
– Data can only be accessed through the functions, so it’s
synchronized

Operating System Concepts – 10th Edition 6.73 Silberschatz, Galvin and Gagne
 A Monitor

Operating System Concepts – 10th Edition 6.74 Silberschatz, Galvin and Gagne
 Monitor Facilities

• Mutual exclusion: only one process can be executing

inside at any time
– Thus, synchronization implicitly achieved by the monitor
– If a second process tries to enter a monitor procedure, it
blocks until the first has left the monitor
• More restrictive than semaphores!
– But easier to use most of the time
– Once inside, a process may discover it can’t
continue, and may decide to block
– Or, allow some other waiting process to continue
Operating System Concepts – 10th Edition 6.75 Silberschatz, Galvin and Gagne
 Condition Variables

• Monitors often used with “condition variables”

• “Condition Variables” are Synchronization Primitives

that enable threads to wait until a particular condition
occurs
• Basically, its just a place to wait
• Using condition variables, processes can wait, or signal others
to continue
• Condition variables can only be accessed from inside a
monitor

Operating System Concepts – 10th Edition 6.76 Silberschatz, Galvin and Gagne
 Operations on Condition Variables
• wait(c)
– release monitor lock, so somebody else can get in
– block until somebody else signals condition
– thus, a condition variable may have a wait queue
• signal(c)
– wake up at most one waiting process/thread
– if no waiting processes, signal is a no-op
– this is different than semaphore Signal.. how?

Operating System Concepts – 10th Edition 6.77 Silberschatz, Galvin and Gagne
 Signaling

• signal(c) means
– Wake one thread waiting on this condition variable
(if any)
– Signaler can keep lock and CPU
– Waiter is made ready, but the signaler continues
•Waiter runs after signaler leaves monitor (or waits)
•Condition is not necessarily true when waiter runs again
–Being woken up is only a hint that something has changed
•Must recheck conditional case (while-loop)

Operating System Concepts – 10th Edition 6.78 Silberschatz, Galvin and Gagne
 Signaling

• Broadcast (or NotifyAll)

– Wake all threads waiting on condition variable
– Avoids need for multiple condition variables
– Often a good idea to use broadcast (unless
you’re sure about signal)

Operating System Concepts – 10th Edition 6.79 Silberschatz, Galvin and Gagne
 Producer/Consumer
lock mutex;
cond_var full, empty;
int i=0;

Producer: Consumer:

void producer(int max) { void consumer(int max) {

while (true) { while (true) {
mutex.lock(); mutex.lock();
while (i == max) { while (i == 0) {
full.wait(&mutex); empty.wait(&mutex);
} }
buf[i] = produce(); consume (buf[i-1]);
i++; i--;
empty.broadcast(); full.broadcast();
mutex.unlock(); mutex.unlock()
} }
} }
Operating System Concepts – 10th Edition 6.80 Silberschatz, Galvin and Gagne
 Producer/Consumer
lock mutex;
cond_var full, empty;
int i=0;

Producer: Consumer:

void producer(int max) { void consumer(int max) {

while (true) { while (true) {
mutex.lock(); mutex.lock();
while (i == max) { while (i == 0) {
full.wait(&mutex); empty.wait(&mutex);
} }
buf[i] = produce(); consume (buf[i-1]);
i++; i--;
empty.broadcast(); full.broadcast();
mutex.unlock(); mutex.unlock()
} }
} }
Operating System Concepts – 10th Edition 6.81 Silberschatz, Galvin and Gagne
 Producer/Consumer
(If Language supports Monitors)

cond_var full, empty;

int i=0;

Producer: Consumer:
//Called from an infinite loop //Called from an infinite loop.
//automatically takes lock //automatically takes lock
on //entry, releases on exit on //entry and releases on exit
void producer(int max) { void consumer(int max) {
while (i == max) { while (i == 0) {
full.wait(); empty.wait();
} }
buf[i] = produce(); consume (buf[i-1]);
i++; i--;
empty.broadcast(); full.broadcast();
} }

Operating System Concepts – 10th Edition 6.82 Silberschatz, Galvin and Gagne
 Readers/Writer
lock wrt; Reader() {
cond_var read_cond, write_cond; wrt.lock();
int writing, read_count; while (writing==1) {
read_cond.wait(&wrt);
Writer() {
wrt.lock(); }
while (read_count > 0) { read_count++;
write_cond.wait(&wrt); wrt.unlock();
}
writing = 1; read();
write(); wrt.lock();
read_count--;
writing = 0;
read_cond.broadcast(); write_cond.broadcast();
wrt.unlock(); wrt.unlock();
} }

Operating System Concepts – 10th Edition 6.83 Silberschatz, Galvin and Gagne
 Readers/Writer (Simplified)
Is this correct?
lock wrt; Reader() {
cond_var write_cond; wrt.lock();
int read_count;
read_count++;
Writer() {
wrt.lock(); wrt.unlock();
while (read_count > 0) {
write_cond.wait(&wrt); read();
}
wrt.lock();
write(); read_count--;
write_cond.broadcast();
wrt.unlock();
wrt.unlock();
}
}

Operating System Concepts – 10th Edition 6.84 Silberschatz, Galvin and Gagne
 A Monitor Solution to the Dining-Philosopher problem

enum {THINKING, HUNGRY, EATING} state[5]; // data

structure
 Philosopher i can set the variable state[i] = EATING only
if his two neighbors are not eating:
• (state[(i+4) % 5] != EATING) and
• (state[(i+1) % 5] != EATING
 We also need to declare condition self[5]; in which
philosopher i can delay himself when he is hungry but is
unable to obtain the chopsticks

Operating System Concepts – 10th Edition 6.85 Silberschatz, Galvin and Gagne
 Monitors to solve the Dining-Philosopher problem
monitor DiningPhilosopher
{ void test(int i) {
enum {THINKING, HUNGRY, EATING} if ((state[(i + 4) % 5] !=
state[5]; EATING) &&
condition self[5]; (state[i] == HUNGRY) &&
void pickup(int i) { (state[(i + 1) % 5] !=
state[i] = HUNGRY; EATING)) {
test(i); state[i] = EATING;
if (state[i] != EATING) self[i].signal();
self[i].wait(); }
} }
void putdown(int i) { initialization code() {
state[i] = THINKING; for (int i = 0; i < 5; i++)
test((i + 4) % 5); state[i] = THINKING;
test((i + 1) % 5); }
} }

Operating System Concepts – 10th Edition 6.86 Silberschatz, Galvin and Gagne
 Alternative Monitor Semantics

• Hoare Semantics:
– When signal/broadcast called, release lock
immediately and execute the waiter
– Allows “while” loop to be replaced with “if”
– Common in theory/books, not in practice

Operating System Concepts – 10th Edition 6.87 Silberschatz, Galvin and Gagne
 Conclusion

• Getting synchronization correct is difficult!

– Many famous pieces of software have had synchronization
bugs

• Need to decide which primitive to use

– Locks the simplest and most common, but also restrictive
– Condition variables and monitors make life a bit easier
– Semaphores hardest to use, but most powerful

Operating System Concepts – 10th Edition 6.88 Silberschatz, Galvin and Gagne
 End of Chapter 6

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne