Chapter 4: Small Examples by Joseph Melnyk

1
Chapter 4 Small Examplesby Joseph Melnyk

• Channels
• A Simple Database
• Management of Multilevel Memory Lazy Caching
• Real-Time Controller Disrete-Event Simulation
• Example of a Process Network
• Broadcast
• Barrier Synchronization
• Readers and Writers
• Semaphores
• Multiple Resource Allocation

2

• Notational Conventions
• single instance of a cat, C
• abbreviated with box b followed by Cs body
• Quantification
• ??x q(x) e(x)?
• ? is a commutative, associative binary operator
• x is the bound variable (or a list of them)
• q(x) is a predicate determining the range of
  bound variables
• e(x) is an expression called the body
• only actions, not methods, may be quantified

3

• Examples
• first creates N partial actions named get(i)
  get(i) includes i as a parameter in its
  pre-condition c.i, pre-procedure semi and body
  B.i
• second creates N positive and N negative
  alternatives with i as a parameter in
  pre-condition, pre-procedure and body

4

• Channels
• Unbounded FIFO channel
• cat with two methods
• total method put (send)
• partial method get (receive) channel may be
  non-empty
• channel r sequence of values sent but not yet
  received

5

• unbounded FIFO channel applications
• Copy
• let in and out be boxes of FifoChannel of type
  integer
• partial action transfer copies element of in to
  out
• Merge
• boxes in1, in2 and out are instances of
  FifoChannel
• partial actions transfer1 and transfer2 read from
  in1 and in2, respectively, and output to out

6

• Bounded FIFO channel
• let channel size N
• ? denotes addition mod N
• messages kept in a circular buffer, b
• f index of oldest message r index of
  youngest message ? 1 k total number of
  messages in the channel

7

• Bounded FIFO channel (contd.)
• let channel size 1
• w contents of channel
• full true ? w contains data

8

• Bounded FIFO channel (contd.)
• Multiplexor
• communicates with consoles i (0?i?9) via ci
  where ci is a word (as above)
• sends output along FifoChannel out
• morei true ? multiplexor hasnt yet received
  an eos message from channel i
• no restrictions on order of partial action
  executions
• fairness any message sent by a console will
  eventually be received and output by the
  multiplexor

9

• Unordered channel
• channel is a bag and get is nondeterministic
• doesnt guarantee every message is eventually
  delivered

10

• so assign index to each message (and let t ?
  smallest index) with index ? t when the message
  is put in the channel
• get removes the message with the smallest index
  and sets t to that index
• there are an unbounded number of calls to get ?
  each message is eventually removed

11

• Task dispatcher
• interacts with clients and servers
• client generates request w/priority of 0 to N
• server gets task from dispatcher when idle and
  processes tasks of priority p or lower
• methods put and get are called by client and
  server, respectively
• ri queue of pending tasks of priority i get
  returns task of highest priority that server can
  process

12

• Disk head scheduler
• user submits access request to filter who orders
  the requests server calls filter for the next
  process to be served
• let ps set of submissions already served rq
  queue of submissions yet to be served r a
  request and i identity of user requesting r
• get accepts a call if there are requests (rq
  ???) it returns r to the server, removes (i,r)
  from rq and adds it to rs
• put accepts a call if this submission was served
  ((i,r) ? ps), rejects otherwise new submissions
  are queued in rq (all calls are rejected until
  the request has been served)

13

• Faulty channel
• can lose messages, duplicate a message an
  unbounded (finite) number of times or permute
  order of messages
• use a bag b to simulate out-of-order delivery
• assign a value n to each message representing the
  number of times to add the message to b
  (simulates message duplication and loss (n0))
• n is nonzero periodically in put to ensure that
  messages that are put repeatedly are eventually
  delivered

14

• A Simple Database
• let D database with total methods insert,
  delete and query
• these methods store one of three parameters in r
  eff, error or ineff

15

• example using DataBase
• let box store DataBase(element) be an instance
  of DataBase with item-type element
• there are two users requesting operations on
  store requests are directed to multiplexor
• multiplexor
• carries out requests returns boolean value for
  the operation (true ? operation was effective)
• outputs log of effective insert and delete
  operations
• xreq and yreq are instances of word (as above)
  for users to send requests to multiplexor
• multiplexor sends sequence of effective requests
  over an unbounded FIFO channel
• xrep and yrep are for the multiplexor to
  communicate with the two users

16

• multiplexor has two partial actions to read from
  the two channels xreq and yreq (from the two
  users)

17

• Management of Multilevel Memory Lazy Caching
• system memory, processors their caches one
  cat each
• two FIFO channels, in and out for each cache
• memory
• Mwrite(d,a) assigns the value at a to d
• Mread(d,a) assigns d to a
• cache
• write(d,a) and read(d,a) as in memory
• C cache memory (C(a) value at a in C)
• lenout number of items in out
• leninT number of true items in in
• idea
• processors continue after write(d,a) by appending
  (d,a) to out read delayed until all previous
  writes are finished
• only a cache u may apply put and get to its out
  channel (which holds all pending writes of the
  form (d,a))
• in has triples of the form (d,a,tag) where tag is
  a boolean these are pending updates to the cache
  due to writes by u or other caches
• partial actions conin and conout consume items
  from in and out, respectively conout also
  appends (d,a,false) to the in channel of all
  caches to notify their respective processors to
  update their cache

18
(No Transcript)
19

• Real-Time Controller Discrete-Event Simulation
• box user
• users0..N set of users that communicate with
  AlarmClock
• set in useri calls set in AlarmClock
  w/parameter d tick in AlarmClock calls WakeUp
  for useru after d clock ticks
• sleep is true in useri after execution of set
  and before execution of WakeUp
• c is the condition under which the user sleeps

20

• cat AlarmClock
• tick advances variable time, and executes any
  wake up calls needed for time time
• eventi list of users who need to woken up at
  time i

21

• Example of a Process Network
• wish to compute sequence of integers of the form
  2i3j5k in increasing order for natural numbers
  i, j, and k
• let H sequence to be computed, then the
  strategy is to compute
• merge merges its argument sequences (all
  increasing) to form an increasing sequence

22

• produce receives 2H, 3H and 5H along
  FifoChannels H2, H3 and H5, respectively it
  merges inputs and puts sequence on channel H
• consume removes items h from H and sends 2h, 3h
  and 5h along FifoChannels H2, H3 and H5,
  respectively
• program Hamming
• produce is similar to merge
• h2 last number received along H2 not yet sent
  on H if all numbers received have already been
  output, then h2 0 h3 and h5 are similar
• read2 receives next value from H2 if h20 read3
  and read5 are similar
• write outputs smalles of h2, h3 and h5 on H when
  they are al nonzero, then sets them to 0
• H initially has just 1 on the channel

23
(No Transcript)
24

• Broadcast
• writers wish to broadcast a sequence of values to
  readers can be done only if all previously
  broadcast values have been read by all readers
• v value to be broadcast n number of readers
  that have read v N readers
• read
• precondition this reader has not read the
  current value of v
• assign a boolean sequence number t to the value
  of v
• readers calls read(s) where s last (boolean)
  sequence number read by this reader (initially, s
  true)
• if t s the reader has read this value, so
  reject if t?s, the reader can read the value and
  both s and n are updated
• writing permitted when all readers have read v
  (so nN)
• t is reversed whenever a new value is written to v

25
(No Transcript)
26

• Barrier Synchronization
• box user
• works in phases
• user can execute phase p1 only after all users
  have completed phase p
• each user has value k, the highest phase it has
  completed
• each user calls sync(k) to advance to phase k1

27

• box barrier
• p highest phase all users have completed
• sync(k) accepts if k p (all users have
  completed phase p)
• N users n number of users that have not
  yet started their phase (p1)
• n is decremented when sync accepts a call
• if n 0, all users have completed phase p so p
  is incremented and n is set to N

28

• variation
• evaluate k p by comparing the lowest bits of k
  and p incrementation inverts the lowest bit
• so use s and t lowest bits of k and p,
  respectively

29

• Readers and Writers
• readers and writers wish to read and write,
  respectively, to a resource
• StartRead and StartWrite give readers and writers
  their desired access to the resource
• readers call EndRead and writers call EndWrite to
  release the resource
• reading/writing are finite so StartReads are
  eventually followed by EndReads (and likewise for
  writing)
• nr number of active readers nw number of
  active writers

30

• Guaranteed Progress for writers
• ensure readers do not permanently overtake
  writers by rejecting calls to StartRead if
  somewriter is waiting to execute StartWrite
• WriteWait true if a call to StartWrite is
  rejected because of active readers

31

• Guaranteed Progress for readers and writers
• as above, introduce a boolean variable ReadWait
  analogous to WriteWait

32

• Starvation freedom for writers
• assign process-id to each writer wq queue of
  writer ids
• StartWrite accepts if nr 0 ? nw 0 and the
  caller is at the head of wq
• pid type for the process-id

33

• Semaphore
• Weak semaphore
• recall that P acquire and V release

34

• Seuss does not require that pre-condition c
  remain true until the process acquires the
  semaphore so we can acquire either of the
  semaphores in the example below
• process not holding a semaphore can release it by
  executing V, so restrict releases to the process
  holding the semaphore only
• holder id of process holding the semaphore
• calls to P and V have the process-id as an
  argument

35

• use tickets
• accepted call on P returns a ticket and calls on
  V have effect only if made by the ticket holder
• PN.pnat(j) places a positive integer into j
• however, a process can still guess the ticket
  value by repeatedly attempting to call V with
  different values

36

• Strong Semaphore
• guarantees absence of individual starvation
• in Seuss, if s is a strong semaphore and
  pre-condition c remains true, then s.P will
  eventually be effective
• P(i) adds i (the calling processs id) to queue q
  if i ?q and grants semaphore to a caller ? its
  available and i is at the head of q

37

• using tickets
• t position of process in q is used as a
  paramter instead of process-id
• f current head of q r last element in q
• P rejects calls but sets t to the processs
  position in q P accepts if t f and the
  semaphore is available
• V releases semaphore if caller shows proper ticket

38

• more secure use of tickets
• assign random integers as ticket values
• place the values in q to avoid starvation
• transient callers (call P only once or very
  rarely) can block other callers from acquiring
  the semaphore if the transient caller is at the
  head of q and never calls P again, everyone blocks

39

• Snoopy semaphore
• holder of the semaphore periodically checks to
  see if any other processes have requested it if
  not, it doesnt release it
• S accepts a call only if the last call on P was
  rejected
• b false if a call on P is accepted and true if
  one is rejected

40

• but no guarantee that a process will ever acquire
  the semaphore
• so use a queue q as in StrongSemaphore
• to check if others want the semaphore, see if q
  is empty to notify the holder that a process is
  requesting the semaphore, queue the process

41

• Multiple Resource Allocation
• problem
• we have a set of resources and a set of processes
• each process is in a state thinking, eating or
  hungry
• thinking processes
• need no resources
• become hungry for a specific subset of resources
• hungry processes
• remain hungry until acquiring all needed
  resources
• then transit to eating state
• every eating processes eventually transits to
  thinking state, releasing all held resources
• solution
• specifies steps for a hungry process to acquire
  resources and protocol for releasing them
• starvation-free if each hungry process eventually
  eats
• deadlock-free if some hungry process eventually
  eats
• associate a semaphore with each process

42

• assumptions
• action for thinking to hungry transition not
  shown its part of an underlying program which
  sets boolean array needs where needsi indicates
  that the process needs resource i
• eating to thinking transition not shown every
  eating process eventually transits to thinking
  and needs and d are unchanged by the transition
• resources numbered 0 to N r array 0..N of
  semaphores, one for each resource
• state holds state of a process (thinking,
  eating or hungry) abbreviation thinking means
  state thinking, etc.
• hungry processes acquire resources in increasing
  order of resource index
• each process has a local variable d such that a
  hungry process has acquired all necessary
  resources from 0 through d-1

43

• A deadlock-free solution
• assume all semaphores are weak semaphores
• process releases all semaphores it holds when in
  thinking state

44

• A starvation-free solution
• everything remains the same, except instead of
  the weak semaphore, use box r0..N
  StrongSemaphore the process-id now has to be
  passed as an argument to rd.P
• A deadlock-free solution using snoop semaphores
• for each process, holdsi true ? this process
  holds semaphore i
• d 0 along with the transition from eating to
  thinking