Operating Systems:

Internals and Design Principles, 6/E

William Stallings
Roadmap
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
Chapter 5 • Semaphores
Concurrency: Mutual • Monitors
Exclusion
Click to edit Master subtitle style and • Message Passing
Synchronization • Readers/Writers Problem

Dave Bremer
9/28/10 Otago Polytechnic, N.Z.
©2008, ice all

Multiple Processes Concurrency

• Central to the design of modern Operating Concurrency arises in:
Systems is managing multiple processes • Multiple applications
– Multiprogramming – Sharing time
– Multiprocessing • Structured applications
– Distributed Processing – Extension of modular design
• Big Issue is Concurrency • Operating system structure
– Managing the interaction of all of these – OS themselves implemented as a set of
processes processes or threads

Key Terms Interleaving and

Overlapping Processes
• Earlier (Ch2) we saw that processes may
be interleaved on uniprocessors
 Interleaving and Difficulties of
Overlapping Processes Concurrency
• And not only interleaved but overlapped • Sharing of global resources
on multi-processors • Optimally managing the allocation of
resources
• Difficult to locate programming errors as
results are not deterministic and
reproducible.

A Simple Example A Simple Example:

On a Multiprocessor
void echo() Process P1 Process P2
{ . .
chin = getchar(); chin = getchar(); .
chout = chin; . chin = getchar();
putchar(chout); chout = chin; chout = chin;
} putchar(chout); .
. putchar(chout);
. .

Enforce Single Access Race Condition

• If we enforce a rule that only one process • A race condition occurs when
may enter the function at a time then: – Multiple processes or threads read and write
• P1 & P2 run on separate processors data items
– They do so in a way where the final result
• P1 enters echo first,
depends on the order of execution of the
– P2 tries to enter but is blocked – P2 suspends processes.
• P1 completes execution • The output depends on who finishes the
– P2 resumes and executes echo race last.
 Operating System Process Interaction
Concerns
• What design and management issues are
raised by the existence of concurrency?
• The OS must
– Keep track of various processes
– Allocate and de-allocate resources
– Protect the data and resources against
interference by other processes.
– Ensure that the processes and outputs are
independent of the processing speed

Competition among Requirements for

Processes for Resources Mutual Exclusion
Three main control problems: • Only one process at a time is allowed in
• Need for Mutual Exclusion the critical section for a resource
– Critical sections • A process that halts in its noncritical
• Deadlock section must do so without interfering with
• Starvation other processes
• No deadlock or starvation

Requirements for Roadmap

Mutual Exclusion
• A process must not be delayed access to • Principals of Concurrency
a critical section when there is no other • Mutual Exclusion: Hardware Support
process using it • Semaphores
• No assumptions are made about relative • Monitors
process speeds or number of processes • Message Passing
• A process remains inside its critical • Readers/Writers Problem
section for a finite time only
 Disabling Interrupts Pseudo-Code
• Uniprocessors only allow interleaving while (true) {
• Interrupt Disabling /* disable interrupts */;
– A process runs until it invokes an operating /* critical section */;
system service or until it is interrupted /* enable interrupts */;
– Disabling interrupts guarantees mutual
exclusion /* remainder */;
– Will not work in multiprocessor architecture }

Special Machine Compare&Swap

Instructions Instruction
• Compare&Swap Instruction int compare_and_swap (int *word,
– also called a “compare and exchange int testval, int newval)
instruction” {
• Exchange Instruction int oldval;
oldval = *word;
if (oldval == testval) *word = newval;
return oldval;
}

Mutual Exclusion (fig 5.2) Exchange instruction

void exchange (int register, int
memory)
{
int temp;
temp = memory;
memory = register;
register = temp;
}
 Exchange Instruction Hardware Mutual
(fig 5.2) Exclusion: 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

Hardware Mutual Roadmap

Exclusion: Disadvantages
• Busy-waiting consumes processor time • Principals of Concurrency
• Starvation is possible when a process • Mutual Exclusion: Hardware Support
leaves a critical section and more than • Semaphores
one process is waiting. • Monitors
– Some process could indefinitely be denied
access.
• Message Passing
• Deadlock is possible
• Readers/Writers Problem

Semaphore Semaphore Primitives

• Semaphore:
– An integer value used for signalling among
processes.
• Only three operations may be performed
on a semaphore, all of which are atomic:
– initialize,
– Decrement (semWait)
– increment. (semSignal)
 Binary Semaphore Strong/Weak
Primitives Semaphore
• A queue is used to hold processes waiting
on the semaphore
– In what order are processes removed from the
queue?
• Strong Semaphores use FIFO
• Weak Semaphores don’t specify the
order of removal from the queue

Example of Strong Example of Semaphore

Semaphore Mechanism Mechanism

Mutual Exclusion Using Processes Using

Semaphores Semaphore
 Producer/Consumer Functions
Problem
• General Situation: • Assume an infinite buffer b with a linear array of
– One or more producers are generating data and elements
placing these in a buffer
Producer Consumer
– A single consumer is taking items out of the buffer
one at time while (true) { while (true) {
– Only one producer or consumer may access the
buffer at any one time /* produce item v while (in <= out)
• The Problem:
– Ensure that the Producer can’t add data into full buffer */ /*do nothing */;
and consumer can’t remove data from empty buffer
b[in] = v; w = b[out];
Producer/Consumer Animation in++; out++;

Buffer Incorrect Solution

Possible Scenario Correct Solution

 Semaphores Bounded Buffer

Semaphores Functions in a
Bounded Buffer
• .

Producer Consumer

while (true) { while (true) {

/* produce item v while (in == out)
*/ /* do nothing
while ((in + 1) % */;
n == out) /* do w = b[out];

Demonstration Roadmap
Animations
• Producer/Consumer • Principals of Concurrency
Illustrates the operation of a producer-consumer
Mutual Exclusion: Hardware Support
–
•
buffer.
• Bounded-Buffer Problem Using Semaphores
• Semaphores
– Demonstrates the bounded-buffer consumer/producer • Monitors
problem using semaphores. • Message Passing
• Readers/Writers Problem
 Monitors Chief characteristics
• The monitor is a programming-language • Local data variables are accessible only
construct that provides equivalent by the monitor
functionality to that of semaphores and • Process enters monitor by invoking one of
that is easier to control. its procedures
• Implemented in a number of programming • Only one process may be executing in the
languages, including monitor at a time
– Concurrent Pascal, Pascal-Plus,
– Modula-2, Modula-3, and Java.

Synchronization Structure of a Monitor

• Synchronisation achieved by condition variables
within a monitor
– only accessible by the monitor.
• Monitor Functions:
– Cwait(c): Suspend execution of the calling process
on condition c

– Csignal(c) Resume execution of some process

blocked after a cwait on the same condition

Bounded Buffer Solution Solution Using Monitor

Using Monitor
 Bounded Roadmap
Buffer Monitor
• Principals of Concurrency
• Mutual Exclusion: Hardware Support
• Semaphores
• Monitors
• Message Passing
• Readers/Writers Problem

Process Interaction Message Passing

• When processes interact with one • The actual function of message passing is
another, two fundamental requirements normally provided in the form of a pair of
must be satisfied: primitives:
– synchronization and • send (destination, message)
– communication. • receive (source, message)
• Message Passing is one solution to the
second requirement
– Added bonus: It works with shared memory
and with distributed systems

Synchronization Blocking send,

Blocking receive
• Communication requires synchronization • Both sender and receiver are blocked until
– Sender must send before receiver can receive message is delivered
• What happens to a process after it issues • Known as a rendezvous
a send or receive primitive? • Allows for tight synchronization between
– Sender and receiver may or may not be processes.
blocking (waiting for message)
 Non-blocking Send Addressing
• More natural for many concurrent • Sendin process need to be able to specify
programming tasks. which process should receive the
• Nonblocking send, blocking receive message
– Sender continues on – Direct addressing
– Receiver is blocked until the requested – Indirect Addressing
message arrives
• Nonblocking send, nonblocking receive
– Neither party is required to wait

Direct Addressing Indirect addressing

• Send primitive includes a specific identifier • Messages are sent to a shared data
of the destination process structure consisting of queues
• Receive primitive could know ahead of • Queues are called mailboxes
time which process a message is • One process sends a message to the
expected mailbox and the other process picks up
• Receive primitive could use source the message from the mailbox
parameter to return a value when the
receive operation has been performed

Indirect Process General Message Format

Communication
 Mutual Exclusion Using Producer/Consumer
Messages Messages

Roadmap Readers/Writers Problem

• Principals of Concurrency • A data area is shared among many processes
• Mutual Exclusion: Hardware Support – Some processes only read the data area, some only
write to the area
• Semaphores • Conditions to satisfy:
• Monitors 1. Multiple readers may read the file at once.
• Message Passing 2. Only one writer at a time may write
If a writer is writing to the file, no reader may read
Readers/Writers Problem
3.
•
it.

interaction of readers and

writers.

Readers have Priority Writers have Priority

Writers have Priority Message Passing

Message Passing