chapter 4: small examples by joseph melnyk
DESCRIPTION
Chapter 4: Small Examples by 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. - PowerPoint PPT PresentationTRANSCRIPT
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