Operating

Systems:
Internals Chapter 6
and Design Concurrency:
Principles
Deadlock and
Starvation
Ninth Edition
By William Stallings

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

 Deadlock
 The permanent blocking of a set of processes that
either compete for system resources or communicate
with each other
 A set of processes is deadlocked when each process
in the set is blocked awaiting an event that can only
be triggered by another blocked process in the set
 Permanent because none of the events is
ever triggered
 No efficient solution in the general case
© 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.
 Resource Categories
Reusable
• Can be safely used by only one process at a time and is not depleted by that
use
• Processors, I/O channels, main and secondary memory, devices, and data
structures such as files, databases, and semaphores

Consumable
• One that can be created (produced) and destroyed (consumed)
• Interrupts, signals, messages, and information
• In I/O buffers

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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Example 2:
Memory Request
 Space is available for allocation of 200Kbytes, and the
following sequence of events occur:
P1 P2
... ...
Request 80 Kbytes; Request 70 Kbytes;
... ...
Request 60 Kbytes; Request 80 Kbytes;

 Deadlock occurs if both processes progress to their

second request
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Consumable Resources
Deadlock
 Consider a pair of processes, in which each process attempts to receive a
message from the other process and then send a message to the other process:

 Deadlock occurs if the Receive is blocking

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

 Deadlock Approaches
 There is no single effective  Deadlock avoidance
strategy that can deal with all  Do not grant a resource
types of deadlock request if this allocation
might lead to deadlock
 Three approaches are common:

 Deadlock prevention  Deadlock detection

 Disallow one of the three  Grant resource requests
necessary conditions for when possible, but
deadlock occurrence, or periodically check for the
prevent circular wait presence of deadlock and
condition from happening take action to recover

© 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.
 Conditions for Deadlock
Mutual
Hold-and-Wait No Pre-emption Circular Wait
Exclusion
• Only one • A process • No resource • A closed
process may may hold can be chain of
use a resource allocated forcibly processes
at a time resources removed from exists, such
• No process while a process that each
may access a awaiting holding it process holds
resource until assignment of at least one
that has been other resource
allocated to resources needed by the
another next process
process in the chain

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

 Deadlock Prevention
Strategy
 Design a system in such a way that the possibility of deadlock
is excluded
 Two main methods:
 Indirect
 Prevent the occurrence of one of the three necessary conditions
 Direct
 Prevent the occurrence of a circular wait

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

 Deadlock Condition
Prevention
 Mutual exclusion
 If access to a resource requires mutual exclusion, then mutual
exclusion must be supported by the OS
 Some resources, such as files, may allow multiple accesses for reads
but only exclusive access for writes
 Even in this case, deadlock can occur if more than one process
requires write permission

 Hold and wait

 Can be prevented by requiring that a process request all of its
required resources at one time and blocking the process until all
requests can be granted simultaneously
© 2017 Pearson Education, Inc.,, NJ. All rights reserved. Hoboken
 Deadlock Condition
Prevention
 No Preemption
 If a process holding certain resources is denied a further request, that
process must release its original resources and request them again
 OS may preempt the second process and require it to release its
resources

 Circular Wait
 The circular wait condition can be prevented by defining a linear
ordering of resource types

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

 Deadlock Avoidance
 Allows the three necessary conditions but makes judicious
choices to assure that the deadlock point is never reached
 A decision is made dynamically whether the current resource
allocation request will, if granted, potentially lead to a
deadlock
 Allows the three necessary conditions but makes judicious
choices to assure that the deadlock point is never
reached
 Requires knowledge of future process requests

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

 Two Approaches to
Deadlock Avoidance

Deadlock
Avoidance

Resource Allocation
Denial Process Initiation
Denial
• Do not grant an
incremental resource • Do not start a process
request to a process if if its demands might
this allocation might lead to deadlock
lead to deadlock

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

 Resource Allocation Denial
 Referred to as the banker’s algorithm
 State of the system reflects the current allocation of resources
to processes
 Safe state is one in which there is at least one sequence of
resource allocations to processes that does not result in a
deadlock
 Unsafe state is a state that is not safe

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

 Figure 6.7 Determination of a Safe State

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

 Figure 6.7 Determination of a Safe State

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

 Figure 6.7 Determination of a Safe State

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

 (d) P3 runs to completion

Figure 6.7 Determination of a Safe State

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

 Figure 6.8 Determination of an Unsafe State
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Deadlock Avoidance
Advantages
 It is not necessary to preempt and rollback processes, as in deadlock
detection
 It is less restrictive than deadlock prevention

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

 Deadlock Avoidance
Restrictions
• Maximum resource requirement for each process must
be stated in advance

• Processes under consideration must be independent and

with no synchronization requirements

• There must be a fixed number of resources to allocate

• No process may exit while holding resources

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

 Deadlock Strategies

Deadlock prevention strategies are very

conservative
• Limit access to resources by imposing restrictions on
processes

Deadlock detection strategies do the opposite

• Resource requests are granted whenever possible

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

 Deadline Detection
Algorithm
Advantages:
• It leads to early
 A check for deadlock can detection
be made as frequently as • The algorithm is
each resource request or, relatively simple
less frequently, depending
on how likely it is for a
deadlock to occur
Disadvantage
• Frequent checks
consume
considerable
processor time

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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Recovery Strategies
 Abort all deadlocked processes
 Back up each deadlocked process to some previously defined
checkpoint and restart all processes
 Successively abort deadlocked processes until deadlock no longer
exists
 Successively preempt resources until deadlock no longer exists

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

 Integrated Deadlock
Strategy
 Rather than attempting to design an OS facility that employs only one of these
strategies, it might be more efficient to use different strategies in different situations
 Group resources into a number of different resource classes
 Use the linear ordering strategy defined previously for the prevention of circular wait to prevent
deadlocks between resource classes
 Within a resource class, use the algorithm that is most appropriate for that class

 Classes of resources
 Swappable space
 Blocks of memory on secondary storage for use in swapping processes
 Process resources
 Assignable devices, such as tape drives, and files
 Main memory
 Assignable to processes in pages or segments
 Internal resources
 Such as I/O channels

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

 Class Strategies
 Within each class the following strategies could be used:
 Swappable space
 Prevention of deadlocks by requiring that all of the required resources that may be used be
allocated at one time, as in the hold-and-wait prevention strategy
 This strategy is reasonable if the maximum storage requirements are known
 Process resources
 Avoidance will often be effective in this category, because it is reasonable to expect
processes to declare ahead of time the resources that they will require in this class
 Prevention by means of resource ordering within this class is also possible
 Main memory
 Prevention by preemption appears to be the most appropriate strategy for main memory
 When a process is preempted, it is simply swapped to secondary memory, freeing space to
resolve the deadlock
 Internal resources
 Prevention by means of resource ordering can be used
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Dining Philosophers Problem
 No two
philosophers can
use the same fork
at the same time
(mutual
exclusion)

 No philosopher
must starve to
death (avoid
deadlock and
starvation)

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

 Figure 6.12 A First Solution to the Dining Philosophers Problem

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

 Figure 6.13 A Second Solution to the Dining Philosophers Problem
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Figure 6.14

A Solution
to the
Dining
Philosophers
Problem
Using a
Monitor

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

 UNIX Concurrency Mechanisms
 UNIX provides a variety of mechanisms for interprocessor
communication and synchronization including:

Shared
Pipes Messages
memory

Semaphores Signals

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

 Pipes
 Circular buffers allowing two processes to
communicate on the producer-consumer model
 First-in-first-out queue, written by one
process and read by another

Two types:

• Named
• Unnamed

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

 Messages
 A block of bytes with an accompanying type
 UNIX provides msgsnd and msgrcv system calls for processes to
engage in message passing
 Associated with each process is a message queue, which functions
like a mailbox

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

 Shared Memory
 Fastest form of interprocess communication
 Common block of virtual memory shared by multiple
processes
 Permission is read-only or read-write for a process
 Mutual exclusion constraints are not part of the shared-
memory facility but must be provided by the processes
using the shared memory

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

 Semaphores
 Generalization of the semWait and semSignal primitives
 No other process may access the semaphore until all operations have completed

Consists of:

• Current value of the semaphore

• Process ID of the last process to operate on the
semaphore
• Number of processes waiting for the semaphore value
to be greater than its current value
• Number of processes waiting for the semaphore value
to be zero
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Signals
 A software mechanism that informs a process of the occurrence of
asynchronous events
 Similar to a hardware interrupt, but does not employ priorities

 A signal is delivered by updating a field in the process table for the

process to which the signal is being sent
 A process may respond to a signal by:
 Performing some default action
 Executing a signal-handler function
 Ignoring the signal

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

 Table 6.2

UNIX Signals

(Table can be found on page 288 in textbook)

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

 Real-time (RT) Signals
 Linux includes all of the concurrency mechanisms found in
other UNIX systems
 Linux also supports real-time (RT) signals
 RT signals differ from standard UNIX signals in three primary
ways:
 Signal delivery in priority order is supported
 Multiple signals can be queued
 With standard signals, no value or message can be sent to the target
process – it is only a notification
 With RT signals it is possible to send a value along with the signal
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Atomic Operations
 Atomic operations execute without interruption and
without interference
 Simplest of the approaches to kernel synchronization
 Two types: Integer Bitmap
Operations Operations
Operate on an Operate on one of
integer variable a sequence of bits
at an arbitrary
memory location
Typically used to indicated by a
implement pointer variable
counters

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

 Table 6.2

Linux Atomic
Operations

(Table can be found on page

289 in textbook)

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

 Spinlocks
 Most common technique for protecting a critical section in Linux
 Can only be acquired by one thread at a time
 Any other thread will keep trying (spinning) until it can acquire the lock
 Built on an integer location in memory that is checked by each
thread before it enters its critical section
 Effective in situations where the wait time for acquiring a lock is
expected to be very short
 Disadvantage:
 Locked-out threads continue to execute in a busy-waiting mode

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

 Table 6.4 Linux Spinlocks (Table can be found on
page 291 in textbook)

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

 Semaphores
 User level:
 Linux provides a semaphore interface corresponding to that in UNIX
SVR4
 Internally:
 Implemented as functions within the kernel and are more efficient
than user-visable semaphores
 Three types of kernel semaphores:
 Binary semaphores
 Counting semaphores

 Reader-writer semaphores

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

 Table 6.5

Linux
Semaphores

(Table can be found on page

293 in textbook)
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Table 6.6

Linux Memory Barrier Operations

SMP = symmetric multiprocessor

UP = uniprocessor

(Table can be found on page 294 in textbook)

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

 Read-Copy-Update
(RCU)
 The RCU mechanism is an advanced lightweight synchronization mechanism
which was integrated into the Linux kernel in 2002

 The RCU is used widely in the Linux kernel

 RCU is also used by other operating systems

 There is a userspace RCU library called liburcu

 The shared resources that the RCU mechanism protects must be accessed via a
pointer

 The RCU mechanism provides access for multiple readers and writers to a
shared resource

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

 Synchronization Primitives

Mutual
exclusion
(mutex) Semaphores
locks
In addition to the
concurrency
mechanisms of
UNIX SVR4, Solaris
supports four thread
synchronization
Condition primitives:
variables Readers/writer
locks

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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Mutual Exclusion (MUTEX) Lock
 Used to ensure only one thread at a time can access the resource
protected by the mutex
 The thread that locks the mutex must be the one that unlocks it
 A thread attempts to acquire a mutex lock by executing the
mutex_enter primitive
 Default blocking policy is a spinlock
 An interrupt-based blocking mechanism is optional

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

 Semaphores

Solaris provides classic counting

semaphores with the following primitives:

• sema_p() Decrements the semaphore,

potentially blocking the thread
• sema_v() Increments the semaphore,
potentially unblocking a waiting thread
• sema_tryp() Decrements the semaphore
if blocking is not required

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

 Readers/Writer Locks
 Allows multiple threads to have simultaneous
read-only access to an object protected by the lock
 Allows a single thread to access the object for
writing at one time, while excluding all readers
 When lock is acquired for writing it takes on the status of
write lock
 If one or more readers have acquired the lock its status is read
lock

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

 Condition Variables

A condition variable
is used to wait until a
Condition variables
particular condition is
must be used in
true
conjunction with a
mutex lock

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

 Windows Concurrency
Mechanisms
 Windows provides synchronization among threads as part of the object
architecture

Most important methods are:

• Executive dispatcher objects
• User mode critical sections
• Slim reader-writer locks
• Condition variables
• Lock-free operations

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

 Wait Functions

Do not The type of

Allow a return until wait
thread to the function
block its specified determines
own criteria the set of
execution have been criteria
met used

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

 Table 6.7

Windows
Synchronization
Objects

(Table can be found on

page 299 in the textbook)
Note: Shaded rows correspond to objects that exist for the sole purpose of synchronization.
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Critical Sections
 Similar mechanism to mutex except that critical sections
can be used only by the threads of a single process
 If the system is a multiprocessor, the code will attempt to
acquire a spin-lock
 As a last resort, if the spinlock cannot be acquired, a
dispatcher object is used to block the thread so that
the kernel can dispatch another thread onto the
processor

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

 Slim Read-Writer Locks
 Windows Vista added a user mode reader-writer
 The reader-writer lock enters the kernel to block only after
attempting to use a spin-lock
 It is slim in the sense that it normally only requires allocation of a
single pointer-sized piece of memory

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

 Condition Variables
 Windows also has condition variables
 The process must declare and initialize a
CONDITION_VARIABLE
 Used with either critical sections or SRW locks
 Used as follows:
1. acquire exclusive lock
2. while (predicate()==FALSE)SleepConditionVariable()
3. perform the protected operation
4. release the lock

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

 Lock-free Synchronization
 Windows also relies heavily on interlocked operations for
synchronization
 Interlocked operations use hardware facilities to guarantee that
memory locations can be read, modified, and written in a single
atomic operation

“Lock-free”

• Synchronizing without taking a software lock

• A thread can never be switched away from a
processor while still holding a lock

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

 Android Interprocess
Communication
 Android adds to the kernel a new capability known as Binder
 Binder provides a lightweight remote procedure call (RPC) capability that is
efficient in terms of both memory and processing requirements
 Also used to mediate all interaction between two processes

 The RPC mechanism works between two processes on the

same system but running on different virtual machines
 The method used for communicating with the Binder is the
ioctl system call
 The ioctl call is a general-purpose system call for device-specific I/O
operations

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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Summary
 UNIX concurrency mechanisms
 Pipes
 Principles of deadlock  Messages
 Shared memory
 Reusable/consumable resources  Semaphores
 Resource allocation graphs  Signals
 Conditions for deadlock  Linux kernel concurrency mechanisms
 Deadlock prevention  Atomic operations
 Spinlocks
 Mutual exclusion
 Semaphores
 Hold and wait
 Barriers
 No preemption
 Solaris thread synchronization primitives
 Circular wait
 Mutual exclusion lock
 Deadlock avoidance  Semaphores
 Process initiation denial  Readers/writer lock

 Resource allocation denial  Condition variables

 Windows concurrency mechanisms
 Deadlock detection  Wait functions
 Deadlock detection algorithm  Dispatcher objects
 Recovery  Critical sections
 Android interprocess communication  Slim reader-writer locks
 Lock-free synchronization
 Integrated deadlock strategy
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.