1

Chapter 4: Small Examplesby Joseph Melnyk

ChannelsA Simple DatabaseManagement of Multilevel Memory: Lazy CachingReal-Time Controller; Disrete-Event SimulationExample of a Process NetworkBroadcastBarrier SynchronizationReaders and WritersSemaphoresMultiple 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 (0i9) 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

18

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

23

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 ts, 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

25

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