Operating Systems CSE 411

1
Operating SystemsCSE 411

• Kernel synchronization, deadlocks
• Dec. 11 2006 - Lecture 31
• Instructor Bhuvan Urgaonkar

2
Symmetric Multi-threading

• Idea Create multiple virtual processors on a
  physical processor
• Illusion provided by hardware
• Called hyper-threading in Intel machines
• The OS sees the machine as an SMP
• Each virtual processor has its own set of
  registers and interrupt handling, cache is shared
• Why Possibility of better parallelism, better
  utilization
• How does it concern the OS?
• From a correctness point of view it does not
• From an efficiency point of view the scheduler
  could exploit it to do better load balancing

3
Synchronization in SMPsKernel Synchronization
4
Synchronization building blocks Atomic
Instructions

• An atomic instruction for a uni-processor would
  not be atomic on an SMP unless special care is
  taken
• In particular, any atomic instruction needs to
  write to a memoy location
• Recall TestAndSet, Swap
• Need special support from the hardware
• Hardware needs to ensure that when a CPU writes
  to a memory location as part of an atomic
  instruction, another CPU can not write the same
  memory location till the first CPU is finished
  with its write
• Given above hardware support, OS support for
  synchronization of user processes same as in
  uni-processors
• Semaphores, monitors
• Kernel synchronization raises some special
  considerations
• Both in uni- and multi-processors

5
Kernel Control Path

• Recall A kernel is a server that answers
  requests issued in two possible ways
• A process causes an exception (E.g., page fault,
  system call)
• An external device sends an interrupt
• Definition Kernel Control Path
• The set of instructions executed in the kernel
  mode to handle a kernel request
• Similar to a process, except much more
  rudimentary
• No descriptor of any kind
• Most modern kernels are re-entrant gt Multiple
  KCPs may be executing simultaneously
• Synchronization problems can occur if two KCPs
  update the same data
• How to synchronize KCP access to shared
  data/resources?

6
Two mechanisms for easy to achieve kernel
synchronization

• Non-preemptible kernel design
• A KCP can not be pre-empted by another one
• Useful only for certain KCPs, such as those that
  have no synch. issues with interrupt handlers
• Not enough for multi-processors since multiple
  CPUs can concurrently access the same data
  structure
• Adopted by many OSes including versions of Linux
  upto 2.4
• Linux 2.6 is pre-emptible faster dispatch times
  for user processes
• Interrupt disabling
• Disable all hardware interrupts before entering a
  critical section and re-enable them right after
  leaving it
• Works for uni-processor in certain situations
• The critical section should not incur an
  exception whose handler has synchronization
  issues with it
• The CS should not get blocked
• What if the CS incurs a page fault?
• Does not work for multi-processors

7
How to synchronize KCP access to shared data?

• Can use semaphores or monitors
• Not always the best solution in multi-processors
• Consider two KCPs running on different CPUs
• If the time to update a shared data structure is
  very short, then semaphores may be an overkill
• Solution Spin Locks
• Do busy wait instead of getting blocked!
• The kernel designers must decide when to use spin
  locks versus semaphores
• Spin locks are useless in uni-processors Why?

8
Deadlocks
9
The Deadlock Problem

• A set of blocked processes each holding a
  resource and waiting to acquire a resource held
  by another process in the set.
• Example
• System has 2 disk drives.
• P1 and P2 each hold one disk drive and each needs
  another one.
• Example
• semaphores A and B, initialized to 1
• P0 P1
• wait (A) wait(B)
• wait (B) wait(A)

10
Bridge Crossing Example

• Traffic only in one direction.
• Each section of a bridge can be viewed as a
  resource.
• If a deadlock occurs, it can be resolved if one
  car backs up (preempt resources and rollback).
• Several cars may have to be backed up if a
  deadlock occurs.
• Starvation is possible.

11
Deadlock and starvation

• Deadlock implies starvation but not the other way
  around
• Recall Dining Philosophers

12
System Model

• Resource types R1, R2, . . ., Rm
• CPU cycles, memory space, I/O devices
• Each resource type Ri has Wi instances.
• Each process utilizes a resource as follows
• request
• use
• release

13
Deadlock Characterization
Deadlock can arise if four conditions hold
simultaneously Note Necessary conditions but
not sufficient

• Mutual exclusion only one process at a time can
  use a resource.
• No preemption a resource can be released only
  voluntarily by the process holding it, after that
  process has completed its task.
• Circular wait there exists a set P0, P1, ,
  Pn of waiting processes such that P0 is waiting
  for a resource that is held by P1, P1 is waiting
  for a resource that is held by
• P2, , Pn1 is waiting for a resource that is
  held by Pn, and Pn is waiting for a resource
  that is held by P0
• gt Hold and wait a process holding at least
  one resource is waiting to acquire
  additional resources held by other
  processes.

14
Resource-Allocation Graph
A set of vertices V and a set of edges E.

• V is partitioned into two types
• P P1, P2, , Pn, the set consisting of all
  the processes in the system.
• R R1, R2, , Rm, the set consisting of all
  resource types in the system.
• request edge directed edge P1 ? Rj
• assignment edge directed edge Rj ? Pi

15
Resource-Allocation Graph (Cont.)

• Process
• Resource Type with 4 instances
• Pi requests instance of Rj
• Pi is holding an instance of Rj

Pi
Rj
Pi
Rj
16
Example of a Resource Allocation Graph
17
Resource Allocation Graph With A Deadlock
18
Graph With A Cycle But No Deadlock
19
Basic Facts

• If graph contains no cycles ? no deadlock.
• If graph contains a cycle ?
• if only one instance per resource type, then
  deadlock.
• if several instances per resource type,
  possibility of deadlock.

20
Methods for Handling Deadlocks

• Ensure that the system will never enter a
  deadlock state
• Deadlock prevention and deadlock avoidance
• Allow the system to enter a deadlock state and
  then recover
• Deadlock detection and recovery
• Ignore the problem and pretend that deadlocks
  never occur in the system used by most operating
  systems, including UNIX
• Some call it the Ostrich approach - why?

21
Plan for remaining classes

• Penultimate class
• A little history of operating systems
• Significant events, important contributions,
  standards
• What is happening now and what is likely to
  happen in the future
• What is hot and what is not
• Where could you (as a student) go from here?
• Related fields
• Last class
• Revision of entire course
• Tips for final
• Both classes
• Questions about the course
• Feedback!

22
Deadlock Prevention
Restrain the ways request can be made.

• Mutual Exclusion not required for sharable
  resources must hold for nonsharable resources.
• Hold and Wait must guarantee that whenever a
  process requests a resource, it does not hold any
  other resources.
• Require process to request and be allocated all
  its resources before it begins execution, or
  allow process to request resources only when the
  process has none.
• Low resource utilization starvation possible.

23
Deadlock Prevention (Cont.)

• No Preemption
• If a process that is holding some resources
  requests another resource that cannot be
  immediately allocated to it, then all resources
  currently being held are released.
• Preempted resources are added to the list of
  resources for which the process is waiting.
• Process will be restarted only when it can regain
  its old resources, as well as the new ones that
  it is requesting.
• Circular Wait impose a total ordering of all
  resource types, and require that each process
  requests resources in an increasing order of
  enumeration.

24
Deadlock Avoidance
Requires that the system has some additional a
priori information available.

• Simplest and most useful model requires that each
  process declare the maximum number of resources
  of each type that it may need.
• The deadlock-avoidance algorithm dynamically
  examines the resource-allocation state to ensure
  that there can never be a circular-wait
  condition.
• Resource-allocation state is defined by the
  number of available and allocated resources, and
  the maximum demands of the processes.

25
Avoidance algorithms

• Single instance of a resource type. Use a
  resource-allocation graph
• Multiple instances of a resource type. Use the
  bankers algorithm

26
Resource-Allocation Graph Scheme

• Claim edge Pi ? Rj indicates that process Pi may
  request resource Rj represented by a dashed
  line.
• Claim edge converts to request edge when a
  process requests a resource.
• Request edge converted to an assignment edge when
  the resource is allocated to the process.
• When a resource is released by a process,
  assignment edge reconverts to a claim edge.
• Resources must be claimed a priori in the system.

27
Resource-Allocation Graph
28
Unsafe State In Resource-Allocation Graph
29
Resource-Allocation Graph Algorithm

• Suppose that process Pi requests a resource Rj
• The request can be granted only if converting the
  request edge to an assignment edge does not
  result in the formation of a cycle in the
  resource allocation graph

30
Deadlock Detection

• Allow system to enter deadlock state
• Detection algorithm
• Recovery scheme
• Terminate (deadlocked) process(es)
• Preempt resources