Download Document

(2.2) In the design of readers/writers problem using monitor, why is it advisable to
keep the ‘protected resource’ external to the monitor?
Solution:
In the design of readers/writers problem using monitor, the ‘protected resource’ (i.e., the
shared file) is kept external to the monitor so that concurrent reads can be performed.
(2.7) Give a readers’ priority solution to readers/writers problem using CSP
Solution:
process readers-writers;
readercount,x:integer(=0);
busy, y : Boolean(=false);
z:real;
*[reader?z -> r-waiting:=true;

~busy; reader?y -> readercount :=readercount + 1;r-waiting:=false;

readercount>0;reader?x -> readercount := readercount + 1;

~busy AND ~r-waiting AND readercount=0;writer?y -> busy := true;

busy;writer?z -> busy := false;
]
(2.9) Write a monitor to solve the readers/writers problem which works as follows:
If readers and writers both are waiting, then it alternates between readers and
writers. Otherwise it processes them normally (i.e., readers concurrently and
writers serially).
Solution:
Readers-writers: monitor;
Begin
Readercount:integer;
Busy:Boolean;
OKtoread,OKtowrite: condition;
Procedure startread;
Begin
If busy or OKtowrite.queue then OKtoread.wait;
readercount := readercount + 1;
If NOT OKtowrite.queue then OKtoread.signal;
(*a reader signals the next waiting reader if there is no waiting writer*)
procedure endread;
begin
readercount := readercount - 1;
if readercount = 0 then OKtowrite.signal;
end endread;
procedure startwrite;
begin
if busy or readercount  0 then OKtowrite.wait;
busy := true;
end startwrite;
procedure endwrite;
begin
busy := false;
if OKtoread.queue then OKtoread.signal else OKtowrite.signal;
end endwrite;
begin(*initialization*)
readercount := 0;
busy := false;
end;
end readers-writers;
(2.11) Give a solution to the producer/consumer problem using ADA
task bounded-buffer is
entry store(x:buffer);
entry remove(y:buffer);
end;
task body bounded-buffer is
ring[0..9] of buffer;
head,tail:integer;
head := 0;
tail := 0;
begin
loop
select
when head < tail + 10 =>
accept store(x:buffer);
ring[head mod 10] := x;
head:= head + 1;
end store;
or
when tail < head =>
accept remove(y:buffer);
ring[tail mod 10];
tail := tail + 1;
end remove;
end select;
end loop;
end bounded-buffer;
2. Compare the remote procedure call feature in Ada and the RPC support
in Sun Unix machines.
Sun RPC
Server name needs to specified
when making a call
XDR filter needs to be specified
for function parameters when
making client calls
More restricted about the size of
data being transmitted. Requires
low level calls for managing
larger size data
Every server call needs to be
registered on the server side.
Clients must pass single pointers
to all objects instead of actual
objects
No support in the protocol
compiler for callback
Ada RPC
Clients use a standard name
server to locate servers and get
the required binding
Function calls look just like local
calls
Large user-defined data structures
are transparently supported.
No per call requirement. Service
registered just once
No restriction as to what data and
the number of parameters passed
Provides support for callback thus
allowing the development of
asynchronous RPC
3. Imagine you are building the distributed operating system support for Ada RPCs.
Identify the various modules (and their functionality) that you might need.
(1) Binding servers
Binding servers used in distributed systems help the caller identify the location (the
system) of the callee. It is also used for “registering” the presence of a RPC server or the
callee.
(2) Communication module
This module is an interface between caller and callee to pass the parameters. This module
takes care of packing and unpacking the in & out parameters.
(3) Concurrent RPC Handler
This module is used to manage concurrent RPCs that might be initiated on the server
side. Basically, this module creates threads needed to handle each RPC and manage their
execution.