Operating

Systems: Chapter 5
Internals Concurrency: Mutual
and Design
Principles Exclusion and
Synchronization
Ninth Edition
By William Stallings

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Multiple Processes
 Operating System design is concerned with the
management of processes and threads:
 Multiprogramming
 The management of multiple processes within a uniprocessor
system
 Multiprocessing
 The management of multiple processes within a multiprocessor
 Distributed Processing
 The management of multiple processes executing on
multiple, distributed computer systems
 The recent proliferation of clusters is a prime example of
this type of system
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Concurrency
Arises in Three Different Contexts:

Multiple
Applications
Structured
Applications Operating
Invented to allow System
processing time to Structure
be shared among Extension of
active applications modular design
and structured
programming OS themselves
implemented as a
set of processes
or threads

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Table 5.1

Some Key
Terms Related
to
Concurrency

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Mutual Exclusion:
Software Approaches
 Software approaches can be implemented for concurrent processes that execute on
a single-processor or a multiprocessor machine with shared main memory
 These approaches usually assume elementary mutual exclusion at the memory
access level
 Simultaneous accesses (reading and/or writing) to the same location in main memory are
serialized by some sort of memory arbiter, although the order of access granting is not
specified ahead of time
 Beyond this, no support in the hardware, operating system, or programming language is
assumed

 Dijkstra reported an algorithm for mutual exclusion for two processes, designed by
the Dutch mathematician Dekker
 Following Dijkstra, we develop the solution in stages
 This approach has the advantage if illustrating many of the common bugs encountered in
developing concurrent programs

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Principles of Concurrency
 Interleaving and overlapping
 Can be viewed as examples of concurrent processing
 Both present the same problems
 Uniprocessor – the relative speed of execution of
processes cannot be predicted
 Depends on activities of other processes
 The way the OS handles interrupts
 Scheduling policies of the OS

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Difficulties of Concurrency
 Sharing of global resources
 Difficult for the OS to manage the allocation
of resources optimally
 Difficult to locate programming errors as
results are not deterministic and reproducible

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Race Condition
 Occurs when multiple processes or
threads read and write data items
 The final result depends on the order of
execution
 The “loser” of the race is the process that
updates last and will determine the final
value of the variable

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Operating System Concerns
 Design and management issues raised by the existence of
concurrency:
 The OS must:

Be able to keep track of various processes

Allocate and de-allocate resources for each active process

Protect the data and physical resources of each process against unintended interference by
other processes

The functioning of a process, and the output it produces, must be independent of the speed at
And which its execution is carried out relative to the speed of other concurrent processes

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Degree of Awareness Relationship Influence that One Potential Control
Process Has on the Problems
Other

Processes unaware of Competition •Results of one •Mutual exclusion Table 5.2

each other process independent
of the action of •Deadlock (renewable
resource)
others
Process
•Starvation
•Timing of process
may be affected Interaction
Processes indirectly Cooperation by •Results of one •Mutual exclusion
aware of each other sharing process may depend
(e.g., shared object) on information •Deadlock (renewable
obtained from others resource)

•Timing of process •Starvation

may be affected
•Data coherence

Processes directly Cooperation by •Results of one •Deadlock

aware of each other communication process may depend (consumable
(have communication on information resource)
primitives available to obtained from others
them) •Starvation
•Timing of process
may be affected

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Resource Competition
 Concurrent processes come into conflict when they are
competing for use of the same resource
 For example: I/O devices, memory, processor time, clock

In the case of competing processes three

control problems must be faced:

• The need for mutual exclusion

• Deadlock
• Starvation
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Cooperation Among
Processes by Sharing

Because data are held

on resources (devices,
memory), the control
Processes may use and problems of mutual
Covers processes that update the shared data Thus the processes exclusion, deadlock,
The control and starvation are again
interact with other without reference to must cooperate to
mechanisms must present
processes without being other processes, but ensure that the data they
ensure the integrity of • The only difference is that
explicitly aware of know that other share are properly
the shared data data items may be accessed in
them processes may have managed two different modes, reading
access to the same data and writing, and only writing
operations must be mutually
exclusive

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Cooperation Among Processes
by Communication
 The various processes participate in a common effort that links all of the
processes

 The communication provides a way to synchronize, or coordinate, the various

activities

 Typically, communication can be characterized as consisting of messages of

some sort

 Primitives for sending and receiving messages may be provided as part of the
programming language or provided by the OS kernel

 Mutual exclusion is not a control requirement for this sort of cooperation

 The problems of deadlock and starvation are still present

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Requirements for Mutual
Exclusion
Any facility or capability that is to provide support
for mutual exclusion should meet the following
requirements:
 Mutual exclusion must be enforced: only one process at a time is allowed into
its critical section, among all processes that have critical sections for the same
resource or shared object
 A process that halts must do so without interfering with other processes
 It must not be possible for a process requiring access to a critical section to be
delayed indefinitely: no deadlock or starvation
 When no process is in a critical section, any process that request entry to its
critical section must be permitted to enter without delay
 No assumptions are made about relative process speeds or number of processes
 A process remains inside its critical section for a finite time only
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Mutual Exclusion:
Hardware Support
 Interrupt Disabling  Disadvantages:
 In a uniprocessor system, concurrent
processes cannot have overlapped
execution; they can only be interleaved  The efficiency of execution
 A process will continue to run until it could be noticeably degraded
invokes an OS service or until it is because the processor is
interrupted limited in its ability to
 Therefore, to guarantee mutual exclusion, interleave processes
it is sufficient to prevent a process from  This approach will not work
being interrupted in a multiprocessor
 This capability can be provided in the form architecture
of primitives defined by the OS kernel for
disabling and enabling interrupts

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Mutual Exclusion:
Hardware Support
 Compare&Swap Instruction
 Also called a “compare and exchange
instruction”
 A compare is made between a memory value
and a test value
 If the values are the same a swap occurs
 Carried out atomically (not subject to
interruption)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Special Machine Instruction:
Advantages
Applicable to any number of processes on
either a single processor or multiple
processors sharing main memory
Simple and easy to verify
It can be used to support multiple critical
sections; each critical section can be defined
by its own variable
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Special Machine Instruction:
Disadvantages
 Busy-waiting is employed
 Thus while a process is waiting for access to a critical section it
continues to consume processor time
 Starvation is possible
 When a process leaves a critical section and more than one
process is waiting, the selection of a waiting process is arbitrary;
some process could indefinitely be denied access
 Deadlock is possible

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Se ma pho r e An integer value used for signaling among processes. Only three
operations may be performed on a semaphore, all of which are
atomic: initialize, decrement, and increment. The decrement
operation may result in the blocking of a process, and the increment
operation may result in the unblocking of a process. Also known as a
counting semaphore or a general semaphore
Binary Semaphore
Mutex
A semaphore that takes on only the values 0 and 1.
Similar to a binary semaphore. A key difference between the two is
Table 5.3
that the process that locks the mutex (sets the value to zero) must be
the one to unlock it (sets the value to 1).
Condition Variable A data type that is used to block a process or thread until a particular
condition is true. Common
Monitor A programming language construct that encapsulates variables,
access procedures and initialization code within an abstract data type.
The monitor's variable may only be accessed via its access
procedures and only one process may be actively accessing the
monitor at any one time. The access procedures are critical sections. Concurrency
A monitor may have a queue of processes that are waiting to access
it.
Event Flags A memory word used as a synchronization mechanism. Application
code may associate a different event with each bit in a flag. A thread
can wait for either a single event or a combination of events by
Mechanisms
checking one or multiple bits in the corresponding flag. The thread is
blocked until all of the required bits are set (AND) or until at least
one of the bits is set (OR).
Mailboxes/Messages A means for two processes to exchange information and that may be
used for synchronization.
Spinlocks Mutual exclusion mechanism in which a process executes in an
infinite loop waiting for the value of a lock variable to indicate
availability.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Semaphore
A variable that has
an integer value • There is no way to inspect or
upon which only manipulate semaphores other
three operations are than these three operations
defined:

1) A semaphore may be initialized to a nonnegative integer value

2) The semWait operation decrements the semaphore value
3) The semSignal operation increments the semaphore value

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Consequences

There is no way to
You don’t know
There is no way to know which process
whether another
know before a process will continue
process is waiting so
decrements a immediately on a
the number of
semaphore whether it uniprocessor system
unblocked processes
will block or not when two processes are
may be zero or one
running concurrently

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Strong/Weak Semaphores
 A queue is used to hold processes waiting on the semaphore

Strong Semaphores
• The process that has been blocked the longest is
released from the queue first (FIFO)

Weak Semaphores
• The order in which processes are removed from the
queue is not specified
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Producer/Consumer Problem

General One or more producers are generating data and placing

Statement: these in a buffer
A single consumer is taking items out of the buffer one at
a time
Only one producer or consumer may access the buffer at
any one time
The
Problem: Ensure that the producer won’t try to
add data into the buffer if its full, and
that the consumer won’t try to remove
data from an empty buffer
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Table 5.4
Possible Scenario for the Program of Figure 5.12
Producer Consumer s n Delay
1 1 0 0
2 semWaitB(s) 0 0 0
3 n++ 0 1 0
4 i f (n==1) 0 1 1
(semSignalB(delay))
5 semSignalB(s) 1 1 1
6 semWaitB(delay) 1 1 0
7 semWaitB(s) 0 1 0
8 n-- 0 0 0
9 semSignalB(s) 1 0 0
10 semWaitB(s) 0 0 0
11 n++ 0 1 0
12 i f (n==1) 0 1 1
(semSignalB(delay))
13 semSignalB(s) 1 1 1
14 i f (n==0) (semWaitB(delay)) 1 1 1
15 semWaitB(s) 0 1 1
16 n-- 0 0 1
Note: White
17 semSignalB(s) 1 0 1
18 i f (n==0) (semWaitB(delay)) 1 0 0
areas
represent the 19 semWaitB(s) 0 0 0
critical
section
20 n-- 0 –1 0
controlled by 21 semSignalB(s) 1 –1 0
semaphore s.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Implementation of
Semaphores
 Imperative that the semWait and semSignal
operations be implemented as atomic primitives
 Can be implemented in hardware or firmware
 Software schemes such as Dekker’s or Peterson’s
algorithms can be used
 Another alternative is to use one of the hardware-
supported schemes for mutual exclusion
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Monitors
 Programming language construct that provides
equivalent functionality to that of semaphores and is
easier to control
 Implemented in a number of programming languages
 Concurrent Pascal, Pascal-Plus, Modula-2, Modula-3, Java
 Has also been implemented as a program library
 Software module consisting of one or more
procedures, an initialization sequence, and local data

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Monitor Characteristics
Local data variables are accessible only by the monitor’s
procedures and not by any external procedure

Process enters monitor by invoking one of its procedures

Only one process may be executing in the monitor at a time

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Synchronization
 A monitor supports synchronization by the use of
condition variables that are contained within the
monitor and accessible only within the monitor
 Condition variables are a special data type in monitors
which are operated on by two 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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Message Passing
 When processes interact with one another two
fundamental requirements must be satisfied:

Synchronization Communication
• To enforce mutual • To exchange
exclusion information

 Message passing is one approach to providing both of

these functions
 Works with distributed systems and shared memory multiprocessor and
uniprocessor systems
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Message Passing
 The actual function is normally provided in the form of
a pair of primitives:
send (destination, message)
receive (source, message)
 A process sends information in the form of a message
to another process designated by a destination
 A process receives information by executing the
receive primitive, indicating the source and the
message
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Synchronization Format
Send Content
blocking Length
nonblocking fixed
Receive variable
blocking
nonblocking Queueing D iscipline
test for arrival FIFO
Priority
Addressing
Direct
send
receive
explicit
implicit
Indirect
static
dynamic
ownership

Table 5.5
Design Characteristics of Message Systems for
Interprocess Communication and Synchronization
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Synchronization
When a r
executed eceive primitive
in a proc is
es s th e
a message two possi re are
Communication of sses bilities:
between two proce n If there
atio
implies synchroniz i
process s no waiting me
between the two i s
arrives s blocked until sage the
o a
execute, r the process co message
abandon n
ing the a tinues to
receive ttempt t
not o
The receiver can ntil
ge u
receive a messa by If a mess
ag
it has been sent been sen e has previously
t
another process received the message is
and exe
continue cution
s

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Blocking Send,
Blocking Receive
 Both sender and receiver are blocked until the
message is delivered
 Sometimes referred to as a rendezvous
 Allows for tight synchronization between
processes

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Nonblocking Send
Nonblocking send, blocking receive
• Sender continues on but receiver is blocked until the
requested message arrives
• Most useful combination
• Sends one or more messages to a variety of destinations as
quickly as possible
• Example -- a service process that exists to provide a service
or resource to other processes

Nonblocking send, nonblocking receive

• Neither party is required to wait

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Addressing

 Schemes for specifying processes in send

and receive primitives fall into two
categories:

Direct Indirect
addressing addressing

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Direct Addressing
 Send primitive includes a specific identifier of
the destination process
 Receive primitive can be handled in one of
two ways:
 Require that the process explicitly designate
a sending process
 Effective for cooperating concurrent processes
 Implicit addressing
 Source parameter of the receive primitive possesses a
value returned when the receive operation has been
performed
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Indirect Addressing

Messages are sent to a

shared data structure Queues are
consisting of queues that referred to as
can temporarily hold mailboxes
messages

One process sends a

Allows for greater message to the mailbox
flexibility in the and the other process picks
use of messages up the message from the
mailbox

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Queueing Discipline
 The simplest queueing discipline is first-in-first-out
 This may not be sufficient if some message are more urgent
than others

 Other alternatives are:

 To allow the specifying of message priority, on the basis of
message type or by designation by the sender
 To allow the receiver to inspect the message queue and
select which message to receive next

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Readers/Writers Problem
 A data area is shared among many processes
 Some processes only read the data area, (readers) and some
only write to the data area (writers)
 Conditions that must be satisfied:
 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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Readers only in the system •wsem set
•no queues

Writers only in the system •wsem and rsem set

•writers queue on wsem

Both readers and writers with read first •wsem set by reader
•rsem set by writer
•all writers queue on wsem
•one reader queues on rsem
•other readers queue on z

Both readers and writers with write first •wsem set by writer
•rsem set by writer
•writers queue on wsem
•one reader queues on rsem
•other readers queue on z

Table 5.6
State of the Process Queues for Program of Figure 5.26
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Summary
 Mutual exclusion: software approaches
 Dekker’s algorithm
 Monitors
 Peterson’s algorithm  Monitor with signal
 Alternate model of monitors with notify
 Principles of concurrency
and broadcast
 Race condition
 OS concerns  Message passing
 Process interaction  Synchronization
 Requirements for mutual exclusion
 Addressing
 Mutual exclusion: hardware support  Message format
 Interrupt disabling  Queueing discipline
 Special machine instructions
 Mutual exclusion
 Semaphores
 Mutual exclusion
 Readers/writers problem
 Producer/consumer problem
 Readers have priority
 Implementation of semaphores  Writers have priority

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.