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 C’s 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 sem[i] 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 (cont’d.) • let channel size = 1 • w = contents of channel • full = true  w contains data

8. Bounded FIFO channel (cont’d.) • Multiplexor • communicates with consoles i (0i9) via c[i] where c[i] is a word (as above) • sends output along FifoChannel out • more[i] = true  multiplexor hasn’t 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 • doesn’t 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 • r[i] = 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 (n=0)) • 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

19. Real-Time Controller; Discrete-Event Simulation • box user • users[0..N] = set of users that communicate with AlarmClock • set in user[i] calls set in AlarmClock w/parameter d; tick in AlarmClock calls WakeUp for user[u] after d clock ticks • sleep is true in user[i] 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 • event[i] = 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 2i*3j*5k 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 2*H, 3*H and 5*H along FifoChannels H2, H3 and H5, respectively; it merges inputs and puts sequence on channel H • consume removes items h from H and sends 2*h, 3*h and 5*h 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 h2=0; 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

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 n=N) • t is reversed whenever a new value is written to v

26. Barrier Synchronization • box user • works in phases • user can execute phase p+1 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 k+1

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 (p+1); • 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 id’s; • 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 process’s 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 process’s 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 doesn’t 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 needs[i] 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 r[0..N]: StrongSemaphore”; the process-id now has to be passed as an argument to r[d].P • A deadlock-free solution using snoop semaphores • for each process, holds[i] = true  this process holds semaphore i • d = 0 along with the transition from eating to thinking