Quicksort Shortest Paths (PowerPoint)

Document Sample
Quicksort Shortest Paths (PowerPoint) Powered By Docstoc
Dining Philosophers

    Lecture 14

      COMP 201

                      Slide 1
What is a Concurrent Program?
        A sequential program has a
        single thread of control.

        A concurrent program has
        multiple threads of control
        allowing it perform multiple
        computations in parallel and to
        control multiple external
        activities which occur at the
        same time.

                                   Slide 2
           Why Concurrent Programming?

• Performance gain from multiprocessing hardware
   – parallelism.
• Increased application throughput
   – an I/O call need only block one thread.
• Increased application responsiveness
   – high priority thread for user requests.
• More appropriate structure
   – for programs which interact with the environment,
     control multiple activities and handle multiple events.
                                                Slide 3
 Do I need to know about concurrent
Concurrency is widespread but error prone.

  Therac - 25 computerised radiation therapy machine
    Concurrent programming errors contributed to accidents
    causing deaths and serious injuries.

  Mars Rover
    Problems with interaction between concurrent tasks
    caused periodic software resets reducing availability for
                                                     Slide 4
Deadlock error

                 Slide 5
Concepts:   system deadlock: no further progress
            four necessary & sufficient conditions

Models:     deadlock - no eligible actions

Practice:   blocked threads

              Aim: deadlock avoidance - to design
              systems where deadlock cannot occur.

                                             Slide 6
        Deadlock: four necessary and
           sufficient conditions
 Serially reusable resources:
the processes involved share resources which they use under mutual
 Incremental acquisition:
processes hold on to resources already allocated to them while waiting
to acquire additional resources.
 No pre-emption:
once acquired by a process, resources cannot be pre-empted (forcibly
withdrawn) but are only released voluntarily.
 Wait-for cycle:
a circular chain (or cycle) of processes exists such that each process
holds a resource which its successor in the cycle is waiting to acquire.
                                                           Slide 7
                   Wait-for cycle
                   Has A awaits B

Has E awaits A            A

                                          B    Has B awaits C

                   D                C
                                        Has C awaits D
  Has D awaits E

                                                 Slide 8
               Dining Philosophers
Five philosophers sit around a
circular table. Each philosopher
                                          3                         2
spends his life alternately                           2

thinking and eating. In the centre
of the table is a large bowl of           3                         1

spaghetti. A philosopher needs
two forks to eat a helping of        4                                  1
spaghetti.                                    4                 0

One fork is placed between each                   0
pair of philosophers and they agree
that each will only use the fork to his
immediate right and left.
                                                      Slide 9
      Dining Philosophers - model
           structure diagram
Each FORK is a          FORK
                                                         lef t
shared resource                              PHIL
with actions get      lef t                                                 right

and put.
                       phil[1]:                                      phil[4]:
When hungry,           PHIL                                          PHIL
each PHIL must                                                              lef t
first get his

right and left          FORK                                          FORK
forks before he
can start eating.    lef t                                                  right

                                     right              lef t          phil[3]:
                      phil[2]:                FORK
                      PHIL                                             PHIL
                                                                 Slide 10
Dining Philosophers

                  Slide 11
Dining Philosophers

                  Slide 12
              ASML specification

• A number of philosophers are sitting around a table.
• Each one has a fork to the left and a fork to the right.
• We model forks as structures with a unique field index.

structure Fork
       index as Integer

                                                  Slide 13
         Abstract class Philosopher
• Philosophers are modelled as having a unique index, what state
  they are currently in and as being capable of two methods:
   – reporting whether they can make a state change (canMove) and
   – performing a state change (move).
• Because the value of the field status can change, a Philosopher
  is a class and not a structure.

abstract class Philosopher
  var status as State = Thinking
  index as Integer
  canMove() as Boolean
  move()                                                    Slide 14
For simplicity we assume that there are a fixed number (four) of true
philosophers (called simply philosophers below) and one fake
philosopher called nobody.
numPhilosophers as Integer = 4
nobody as Philosopher = undef
Likewise we have four forks.
numForks as Integer = numPhilosophers
forks as Set of Fork = { Fork(i) | i ∈ {1..numForks} }
The fork to the left of a philosopher has the same index as the
philosopher. The fork to the right of a philosopher has the next
higher index (modulo the number of philosophers).
left(p as Philosopher) as Fork
        return Fork(p.index)
right(p as Philosopher) as Fork
        return Fork(p.index mod numPhilosophers + Slide 15
           Philosopher’s lifecycle
• A thinking philosopher has no forks.
                          (Who needs a fork to think?)
• A thinking philosopher may become hungry.
• A hungry philosopher tries to grab the fork to the
  left and thus becomes a
                hungry philosopher with a left fork.
• But one fork is not enough: a philosopher starts
  eating only upon obtaining both forks.
• The fork to right can be obtained only if it is not
  being used.
• From eating, there is only one place to go: back to
  thinking after putting down both forks.
                                              Slide 16
 A successful philosopher's lifecycle is this
         Thinking                           Hungry

          Eating                       HungryWithLeftFork

enum State
     Thinking; Hungry; HungryWithLeftFork; Eating
Initially nobody has a fork.
var holder as Map of Fork to Philosopher =
                                     { f ↦ nobody | f ∈ forks }
                                                   Slide 17
            Greedy Philosophers
• A greedy philosopher never puts down a fork
  until (s)he has eaten and starts thinking.
• This can lead to deadlock.
• The behaviour has been made a little fancier by
  introducing a random amount of thinking and
  eating for a fixed amount of time
  – a thinking philosopher will remain thinking about 80
    percent of the time.

                                              Slide 18
class greedyPhilosopher extends Philosopher
 var bites as Integer = 0
   match status
       Thinking : if (any i | i ∈ {1..10}) < 3 then // usually they prefer to think
                       status := Hungry
       Hungry : if holder(left(me)) = nobody then
                       holder(left(me)) := me
                       status := HungryWithLeftFork
                : if holder(right(me)) = nobody then
                      holder(right(me)) := me
                      status := Eating
                      bites := 3 // the fixed number of bites
       Eating : if bites > 0 then
                          bites := bites - 1
                else      holder(left(me)) := nobody
                          holder(right(me)) := nobody
                          status := Thinking                        Slide 19
      Extracting the conditions from the method move yields the
     function canMove which indicates whether the philosopher
                    can make a state change or not.

class greedyPhilosopher...
canMove() as Boolean
 return status = Thinking ∨
       (status = Hungry ∧ holder(left(me)) = nobody) ∨
       (status = HungryWithLeftFork ∧ holder(right(me)) = nobody) ∨
       status = Eating
asString() as String
 return "Greedy #" + index

                                                      Slide 20
         Generous Philosophers
• A generous philosopher does not insist on
  following a successful philosophical life.
• After picking up the left fork, but finding that
  the right fork is not available, a generous
  philosopher drops the left fork and goes back to
  think some more.
• So if all philosophers are generous, then there is
  no deadlock, but starvation is possible.

                                           Slide 21
class generousPhilosopher extends Philosopher
   match status
      Thinking : status := Hungry
      Hungry : if holder(left(me)) = nobody then
                       holder(left(me)) := me
                       status := HungryWithLeftFork
                : if holder(right(me)) = nobody then
                       holder(right(me)) := me
                       status := Eating
                  else // someone else is holding the right fork put
                        // the left one down and try again another time
                       holder(left(me)) := nobody
                       status := Thinking
      Eating : holder(left(me)) := nobody
                  holder(right(me)) := nobody
                  status := Thinking                       Slide 22
                       Notice that
   the conditions which indicate whether a generous
  philosopher can make a state change or not are more
       liberal than those for greedy philosophers.

class generousPhilosopher...
canMove() as Boolean
 return status = Thinking ∨
      (status = Hungry ∧ holder(left(me)) = nobody) ∨
       status = HungryWithLeftFork ∨
       status = Eating
asString() as String return "Generous #" + index

                                                   Slide 23
A successful generous philosopher's
          lifecycle is this

 Thinking                   Hungry

  Eating                HungryWithLeftFork

                                  Slide 24
                 The Scheduler
Here is one possible scheduler:
  – From the set that it is given,
     • it chooses a philosopher that can make a state transition
                                    and then
     • fires the state transition.
  – If no philosopher can make a step, then
     • the system is deadlocked and
     • an exception is thrown.

                                                      Slide 25
structure deadlockException implements RuntimeException
      message as String
      describe() as String
        return "Deadlock: " + message

schedule(ps as Set of Philosopher, i as Integer)
      choose p ∈ ps where p.canMove()
             step   currentStatus = p.status
             step   WriteLine(p + " was " + currentStatus + ",
                    but now is " + p.status)
                throw deadlockException("after " + i + " steps")
                                                   Slide 26
        The Main Program
• The main program tries to run the above
  schedule 1000 times, and is ready to catch
  the exception thrown if the system
• You may choose which type of philosopher
  to schedule, just comment out one of the
  "greedy" or "generous" lines in the code.

                                     Slide 27
           The Main Program (code)
 phils = { new greedyPhilosopher(i) as Philosopher | i ∈
                                        [1..numPhilosophers] }
 //phils = { new generousPhilosopher(i) as Philosopher | i ∈
                                         [1..numPhilosophers] }
 try step foreach i ∈ [1..1000]
         schedule( phils, i )
         d as deadlockException : WriteLine(d.describe())

                                                    Slide 28
• Concepts
   – deadlock: no futher progress
   – four necessary and sufficient conditions:
      • serially reusable resources
      • incremental acquisition
                                        Aim: deadlock avoidance
      • no preemption                   - to design systems where
                                        deadlock cannot occur.
      • wait-for cycle
• Models
   – no eligable actions (analysis gives shortest path trace)
• Practice
   – blocked threads

                                                      Slide 29