(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 / Ada RPC
Server name needs to specified when making a call / Clients use a standard name server to locate servers and get the required binding
XDR filter needs to be specified for function parameters when making client calls / Function calls look just like local calls
More restricted about the size of data being transmitted. Requires low level calls for managing larger size data / Large user-defined data structures are transparently supported.
Every server call needs to be registered on the server side. / No per call requirement. Service registered just once
Clients must pass single pointers to all objects instead of actual objects / No restriction as to what data and the number of parameters passed
No support in the protocol compiler for callback / 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.