CS 771/871 Operating Systems
[ Home | Class
Roster | Syllabus | Status | Glossary | Search
| Course Notes]
Mid Term Exam and Discussion
Question 1
Vector Clocks can be used to synchronize a set of
communicating processes (e.g. for Group Communications in
ISIS). However, it is assumed that the set of communicating
processes is known and fixed. Consider the case where two
sets of communicating processes are using vector clocks to
synchronize their events unaware of each other's existence.
Assume that at some time, it is necessary for the two groups
to join into one and synchronize all future events. Describe
an extension to vector clocks which will allow them to be
used for this newly formed supergroup.
One can distinguish between the
concepts of vector
clocks in general and their particular
use in ISIS
for message sequencing of group broadcast messages.
I accepted both usages.
General Vector Clocks:
There is not inherent difficulty is
added the second group since no communications has happened
between the groups it is the same as a member of a group
which has not communicated up to this point (and hence
everyone has 0 for its clock meaning nothing done on any
other processors depended on information from the
uncommunicating process). NOTE: You must set the newly added
processors to 0. If you set to the value of the processes own
clock, then no communication could happen until each process
in the new group recieved that last message. But such is not
necessary.
NAMING: The design problem is naming.
Since processes are assigned a known place in the vector,
adding processes will require an agreement on the new naming.
The given implementation of vector clocks required agreement
from all processe as to the assignment of slots in the
vector. Hence the join will also require some agreement
protocol . There are several solutions:
-
Name all processors from 1 to
m+n (where n = #process in first group and m=
#proceses in second group). Problem is updating all
places where the name appeared. could reuse names
from one group, but other group must adjust its
naming.
-
Use two level naming (group
and old process number in group. implement vector
clock as an array of vector clocks, update happens on
entire array. Still must agree on which vector clock
goes with which group.
-
Use unique
"symbolic" names and table instead of
vector. table needs an iterator function for updating
all clocks. This does not require prior agreement of
set of communicating processes.
SYNCHRONIZATION OF JOIN: Except for
the last naming structure, there must be a synchronization
point that occurs at the join where the processes switch over
to the expanded vector clock. Otherwise messages with old
vectors clocks will be circulating and causing confusion with
the new ones. One could propose a "join" message
sent from one group to another which negotiates new vector
clock, including assignment of names and flushing of old
messages.
Broadcast Message Sequencing in
ISIS
In ISIS vector clocks are used to sequence
broadcast messages (p. 112 text, p.107 Singhal). No message
is delivered until all messages seen by sender are also seen
by receiver. There are a similar set of problems as above
(naming agreement and synchronization) However it is imporant
to bring the new vector entries for each process up to date,
otherwise there would be deadlock. Consider if process P1
from old group 1 has sent 5 messages, and process P5 from old
group 2 has not seen any messages from P1, then it would wait
for every upon recieving a timestamp with P1's slot set to 5
waiting for these old messages from P1 to appear. There are
two choices:
- Declare that old broadcast messages have no
relevance to the new group. Flush messsages and set
all vector locations to 0. (Like a commit or
checkpoint) Or could set it to the sequence number
for every process of its last message.
- Keep a log of all old messages and send them
to the process which missed them earlier (adjusting
process names as agreed), then continue normally.
Grading
- Reasonable Data Structure and
Overall Approach (5 points)
- Synchronization protocol
identifed (3 points)
- Naming agreement defined (2
points).
Question 2
A distributed system may have multiple,
independent critical regions. Imagine that process 0 wants to
enter critical region A and process 1 wants to enter critical
region B. Can Ricart and Agrawala's algorithm lead to
deadlocks? explain you answer.
Ricart and Agrawala's algorithm does
allow for entering specific critical regions (otherwise, if
there was only one critical region there is no problem). If
critical regions are nested in arbitrary order it is possible
to have a deadlock. That is if process 0 wanted to enter
region B while in A and process 1 wants to enter A while in B
(10 points). However you could take the example in a
minimilistic sense and say no dealocks possible since only
one critical region is desired and regiosn are independent
(the question is meant to be more general with this as a
example of the kind of interaction possible).
Grading
Question 3
In this problem you are to compare reading a
file using a single-threaded file server and a multi-threaded
server. It takes 15 msec to get a request for work, dispatch
it, and do the rest of the necessary processing, assuming
that the data needed are in the block cache. If a disk
operation is needed, as is the case one-third of the time, an
additional 75 msec is required, during which time the thread
sleeps. How many requests/sec can the server handle if it is
single threaded? If it is multithreaded?
Single Thread: 15msec + 1/3(75msec) =
40msec/request = 25 requests/sec (5 points)
Multi Thread: 15msec/request (all disk time is in parallel) =
66.7 requests/sec
assuming that there is always a request waiting (ie. this is
the max throughput)
This assumes that there will be multiple disks
active, otherwise the disk could become the bottleneck. In
the extreme with only one disk, 75msec/request * 1/3 =
25msec/request (on average) = 40 requests/sec (5 points).
Grading
If no discussion about
possibility of disk bottleneck -3
Question 4
In class the receiver initiated processor
allocation algorithms assumed task pre-emption at the sender
site. Devise an approach which is receiver-initiated but
non-pre-emptive. Discuss the tradeoffs of your approach with
the receiver initiated pre-emptive one.
Since the probablity of a receiver
initiated request arriving at a sender precisely when a new
job enters the system is near 0, the sender should queue the
availability of the excess capacity at the receiver (7
points). The next job which arrives will be sent to the
receiver, assuming the sender is still overloaded. Of course,
the sender doesn't know when the next job will arrive. Nor
does it know if the receiver will still be receptive at this
time. To reduce the time for a sender to get a new job, the
receiver could send to several senders (+2). Then the first
sender with new work, will avail itself of the reciever's
excess capacity. To handle the case when the receiver losses
its excess capacity (either through internally or externally
generated work). the sender should be prepared for its new
job to be rejected (so perhaps it should poll the receiver
before actually sending the job) (3points).
Notice one could adapt part of the Adaptive symmetrical
algorithm which keeps list of receiver.
Question 5
When a computation runs for a long time, it
is sometimes wise to make checkpoints periodically, that is,
to save the state of the process on stable storage in case it
crashes. In that way, the process can be restarted from the
checkpoint instead of from the beginning. Devise a way of
checkpointing a computation that consists of multiple
processes running in parallel.
This is a thorny problem since
communications between processes is a side effect of
execution. So rolling a process back to a checkpoint means
that all communications between the last checkpoint at the
point of failure will be redone (5 points). This could lead
to confusion for those processes which did not fail and which
therefore receive the message twice. Messages could have
sequence numbers so that resent messages are ignored
(5points). Or checkpoints could be done just after
communication occurs (but of course the process could fail
after the message but before the checkpoint). Checkpoints
could be incorporated into atomic actions (5 points). Thus
the commit phase of an atomic action will also checkpoint the
process. If all communications between processes occur inside
an atomic action, this would work well. One problem with this
approach is for a set of processes which perform atomic
actions only with proper subsets of the processes. There may
be some processes which will not be checkpointed for a long
time.
Another solution is to define synchronization points where
all processes checkpoint (5 points). This could be coded in
at appropriate points, or a message could be sent from a
checkpoint coordinator to every processes requesting a
checkpoint at this time. (this is in effect like a commit -
so could use the two phase commit protocol).
Question 6
In class we discussed a solution to problem
25 in Chapter 4 (p 244 of text) in which the critical path
was placed on one processor. Is the placing of the processes
from the critical path on a single processor optimal (for
that set of processes)? Give an algorithm which finds the
critical path in a static schedule. (extra credit: give the
algorithmic complexity of this algorithm).
Clearly the processes in a critical
path cannot be executing in parallel. Placing them on
different processors means that a synchronization message
must be sent between them which is not as efficient as
synchronizing on a single processor. So the fastest way to
execute these processes is on a single machine. (5 points)
The critical path is the longest path in a dependency graph.
Nodes in graph are processes and arcs are messages between processes
Data structures
S : Set of {
N : process node
in : integer // number of incoming link
out : set of nodes // outgoing links
time : execution time of process
cost : integer // cost of longest path through this node
parent : node // parent node on longest path
}
Frontier : set of process nodes
Algorithm:
Frontier = {starting process}; //assume only one - could always introduced a dummy starting process which takes no time).
Set cost of this process = 0;
While Frontier is not empty do
P = any process in the Frontier set;
remove P from Frontier;
For all processes Q in the P.out do
if P.cost + P.time > Q.cost then do
Q.cost = P.cost + P.time;
Q.parent = P;
Decrement Q.in;
if Q.in == 0 then add Q to Frontier;
R = process with max cost + time among those with empty out set
Set critical path = backwards traversal from R using parent
(5 points)
NOTE: simple adaptation of shortest
path algorithm is not enough, since depends on monotonic
increasing path lengths in strict order.
Complexity. Order of number of
processes and dependency links.
Question 7
In the approach to cache consistency using
leases, is it really essential that the clocks are
synchronized? If not, what is required.
No, All that is needed is to bound
the maximum that a lease could be in effect.
There can be two ways to construct a lease.
1) Lease is for a given period of time (e.g. 3 seconds)
2) Lease has an ending clock time stipulated (4:15.500 AM
EST)
Looking at contruct 1.
There are two factors which effect the bound. First is the
amount that a clock can be slower or faster than another
clock. Second is the maximum delay in delivering lease (and
thus starting the lease clock at the recieving process). For
example, if the lease is nominally for 1 second and the
maximum that a clock could be off is 1% and the maximum delay
to delivering a lease is 10msec, then after 1011 msec all
leases would be guaranteed to have expired. It doesn't matter
how close the processors clocks are they just need to be used
as timers.
Looking at 2:
Again we need to know the maximum amount that two clocks can
be out of sync. If it is t (seconds), then the lease will
expire by ending time + t.
Copyright chris wild 1996.
For problems or questions regarding this web contact [Dr. Wild].
Last updated: October 30, 1996.