Lecture #7

Administrivia

• lab 1 solution

• assignment 1 solution

  • Golang solution

• tour of /proc

• midterm

  • ground rules
  • study guide?

• lab 2/ass 2: due Tuesday this week & next

  • Thursday OK

Our Story So Far

• threads vs. processes: depends on the problem

• deadlock: mutal dependency

• starvation: thread/process does not get its turn

• Posix threads (pthreads): low-level interface

  • bypass language type system

• critical section: region of code that only one process at a time may execute

• goals/requirements for critical section

  • mutual exclusion
  • progress (when critical section is available, a waiting process must be chosen)
  • bounded waiting (every thread/process eventually gets its turn)

• race condition: incorrect/inconsisten results due to unfortunate timing

• semaphore

• mutex

• condition variable

• monitor

• Decker's algorithm combines two separate approaches which are individually problematic

• modern hardware requires hardware support

  • e.g. test-and-set or swap instructions

• semaphore protects a resource

• mutex protects code (mutual exclusion)

• semaphore = mutex + counter + condition variable

• semaphore:

  • P(): proben/wait/down (get resource)
  • V(): verhogen/signal/up (release resource)

waiting for resource/condition using semaphore & condition variable:

acquire lock (mutex)
while ! resource
  pthread_[timed_]wait(cond_var, lock[, timeout])
critical section
signal cond_var
release lock

alt pattern:

acquire lock
while !resource
  wait(cond, lock)
assert ownership of lock
release lock
non-critical code
acquire lock
release resource
signal cond
release lock

• monitor: language-level support
  • simulate in C++ using RAII
    • consturctor locks mutex
    • destructor releases mutex
  • C++ destructor is called automagically when variable leaves scope

Dining Philosphers Problem

• classic toy problem to demonstrate concurrency
  • 5 philosophers sitting around table
  • 5 chopsticks (one left & one right of each philosopher)
  • philosopher has 3 states
    • thinking
    • hungry
    • eating
  • philosopher requires both chopsticks to eat
  • goal: avoid deadlock without letting one of the philosophers starve

philosopher: deadlock

get left chopstick
get right chopstick
eat
release right chopstick
release left chopstick

Sleeping Barbers Problem

• sounds silly, but is yet another classical illustration of concurrency

• barber sleeps until he gets a customer

• when customer arrives:

  • if barber is sleeping, wake barber
  • otherwise, if chair is available in waiting room, take chair
  • else leave

• when barber finishes with a customer:

  • if customer is waiting, get customer
  • else go back to sleep

• with concurrency, if two customers arrive at the same time, both may try to take the same barber or waiting-room chair

• assignment 2

Deadlocks

• gridlock: traffic at intersection (grid = blocks)
  • no-one may proceed

TODO: diagram

• prevent girdlock: don't enter intersection unless you can proceed past the intersection

• multiple resources (or resource classes: slightly more complex problem)

  • e.g. CPU, memory, I/O devices, ...

• process/thread acquires & releases exclusive access to resource

• informally, a deadlock occurs when a process P1 holds a resource RA and is waiting on RB while the process P2 holds RB and is waiting on RA

  • dependencies may be more complex: P1 <- RA <- P2 <- RB <- P3 <- ... <- RZ and RZ <- P1

TODO: diagram

• dealing with deadlocks: three basic approaches

  1. prevention/avoidance
     • ensure that the system can never enter a deadlock state
  2. detection & recovery
  3. ostrich (head-in-the-sand)
     • ignore the problem
     • what most OSes do anyway
     • user response: "why is this taking so long?"
       • ==> user kills & restarts process

• deadlocks occur only if all of the following conditions are met

  1. mutual exclusion: exclusive access to resource
  2. hold & wait
  3. no preemption: process must voluntarily release held resources
  4. circular wait
     • for individual resources: cycle in 2-color resource-allocation graph
     • cannot use graph algorithm for resource classes (e.g. any printer will do, not just the one on the third floor)

TODO: diagram

• deadlock avoidance: attack one of the 4 conditions

  1. disallow mutual exclusion
  2. disallow hold or disallow wait
     1. require all resources to be allocated at startup (no waiting)
        • ==> low resource utilization
     2. allow resource requests only when process has none (no holding)
        • ==> starvation
  3. allow pre-emption
  4. prevent circular wait
     • strict ordering of resources
     • process may only request resources in increasing order

• deadlock detection: construct resource allocation graph & look for cycle

  • individual resources only, does not work for resource classes

• recovery

  1. kill process(es)
     1. abort all deadlocked processes
     2. abort one process at a time until cycle is broken
  2. preempt resource(s)
     • choose "victim" & roll back
     • select different victim each time (otherwise: starvation)