BLOCK 1 UNIT 3

INERPROCESS COMMUNICATION AND SYNCHRONIZATION

Q1. Define inter-r!"e## "!$$%ni"&ti!n 'IPC(.
Ans: Inter-process communication (IPC) is a capability supported by operating system
that allows one process to communicate with another process. The processes can be
running on the same computer or on different computers connected through a networ.
IPC enables one application to control another application.
Q). E*+&in t,e t-! "!$+i$ent&r. inter-r!"e## "!$$%ni"&ti!n t.e#.
Ans: The two complimentary inter-process communication types are e!plained below:
'&( S,&re/ Me$!r. S.#te$
"hared memory systems re#uire communication processes to share some $ariables. The
processes are e!pected to e!change information through the use of these shared $ariables.
In a shared memory system% the responsibility for pro$iding communication rests with
the application programmers. The operating system only needs to pro$ide shared
memory.
'0( Me##&1e P&##in1 S.#te$
&essage passing system allows communication processes to e!change messages. In this
scheme% the responsibility rests with the operating system itself. The function of message
passing system is to allow processes to communicate with each other without the need to
resort to shared $ariable. An inter-process communication facility basically pro$ides two
operations: send (message) and recei$e (message).
Q3. E*+&in /ire"t &n/ in/ire"t "!$$%ni"&ti!n.
Ans: 'irect and indirect communications are e!plained below:
'&( Dire"t C!$$%ni"&ti!n
In direct communication% each process that wants to send or recei$ed a message must
e!plicitly name the recipient or sender of the communication. In this case% the send and
recei$e primiti$es are defined as follows:
"end(P% message) To send a message to process P
(ecei$e ()% message) To recei$e a message from process P
This scheme shows the symmetry in addressing i.e. both the sender and the recei$er ha$e
to name one another in order to communicate.
'0( In/ire"t C!$$%ni"&ti!n
*ith indirect communication% the messages are sent to and recei$ed from a mailbo!. A
mailbo! can be abstractly $iewed as a ob+ect into which messages may be place and from
which messages bay be remo$ed by processes. In order to distinguish one communicates
with some other process by a number of different mailbo!es. The send and recei$e
primiti$es are defined as follows:
"end (A% message) To send a message to the mailbo! A
(ecei$e (A% message) To recei$e a message from the mailbo! A
Q2. 3,&t i# "&&"it. +in45 E*+&in t,e /ifferent t.e# !f "&&"it. +in4.
Ans: A lin has some capacity that determines the number of messages that can
temporarily reside in it. This is nown as capacity lin.
The different types of capacity lin are e!plained below:
'&( Zer! C&&"it.
This lin has a message #ueue length of ,ero% i.e. no message can wait in it. The sender
must wait until the recipient recei$es the message.
'0( B!%n/e/ C&&"it.
This lin has a limited message #ueue length of n% i.e. at most n messages can reside in it.
If a new message is sent% and the #ueue is not full% it is placed in the #ueue either by
copying the message or by eeping a pointer to the message and the sender should
continue e!ecution without waiting. -therwise% the sender must be delayed until space is
a$ailable in the #ueue.
'"( Un0!%n/e/ C&&"it.
This #ueue has potentially infinite length i.e. any number of messages can wait in it. This
is why the sender is ne$er delayed.
Q6. 3,&t i# #eri&+i7&ti!n5 E*+&in t,e t-! #tr&te1ie# !f #eri&+i7in1 r!"e##e#.
Ans: The ey idea in process synchroni,ation is seriali,ation. This means that we ha$e
to go to some pains to undo the wor we ha$e put into maing an operating system
perform se$eral tass in parallel.
There are essentially two categories to seriali,ing processes in a multitasing
en$ironment which are gi$en below:
(a) The scheduler can be disabled for a short period of time% to pre$ent control being
gi$en to another process during a critical action lie modifying shared data. This
method is $ery inefficient on multiprocessor machines% since all other processors ha$e
to be halted e$ery time one wishes to e!ecute a critical section.
(b) A protocol can be introduced which all programs sharing data must obey. The
protocol ensures that processes ha$e to #ueue up to gain access to shared data. A
process which ignores the protocol ignores it at their own peril. This method wors
on multiprocessor machines also% though it is more difficult to $isuali,e.
Q8. Define $%te*e#. 9i:e t,e ",&r&"teri#ti" r!ertie# !f "riti"&+ #e"ti!n !f
$%te*e#.
Ans: *hen two ore more processes must share the same ob+ect% an arbitration
mechanism is needed so that they do not try to use it at the same time. The particular
ob+ect being shared does not ha$e a great impact on the choice of such mechanisms.
The characteristic properties of the code that form the critical section are:
(i) Codes that refer one or more $ariables in a read update write fashion while any of
those $ariables is possibly being altered by another thread.
(ii) Codes that alter one or more $ariable that are possibly being referenced in need-
update-write fashion by another thread.
(iii) Codes use a data structure while any part of it is possibly being altered by another
thread.
(i$)Codes alter any part of a data structure while it possibly in use by another thread.
Q;. 3,&t &re t,e /r&-0&"4# !f #-it",in1 !ff interr%t# in $%te*e# #!+%ti!n#5
Ans: The drawbacs of switching of interrupts are gi$en below:
(a) &asing interrupts can be dangerous . there is always the possibility that important
interrupts will be missed.
(b) It is not general enough in a multi-processor en$ironment% since interrupts will
continue to be ser$iced by other processors . so all processors would ha$e to be
switched off.
(c) It is too harsh. *e only need to pre$ent two programs from being in their critical
sections simultaneously if they share the same data. Programs A and / might share
different data to programs C and ' so why should they wait for C and '0
Q<. 9i:e t,e /ifferent &+1!rit,$# f!r #!+:in1 $%t%&+ e*"+%#i!n r!0+e$.
Ans: The different algorithms for sol$ing mutual e!clusion problem are gi$en below:
'&( 9L Peter#!n S!+%ti!n
In 1231 4.5. Peterson disco$ered a simple algorithm for achie$ing mutual e!clusion
between two processes with PI' e#ual to 6 and 1. The code is gi$en below:
int turn;
int interested[2];
void Get_Mutex(int pid)
{
int other;
other = 1 pid;
interested[process] = true;
turn = pid;
while(turn==pid && interested[other])
{
!oop until no one else is interested
"
"
#ele$se_Mutex(int pid)
{
%nterested[pid]=&$lse;
"
'0( De44er S!+%ti!n
'eer7s algorithm uses busy waiting and wors for only two processes. The basic idea is
that processes record their interest in entering a critical section and they tae turns when
both need entry at the same time. 'eer7s solution is shown below:
t'pe processed = ()1;
v$r need*$rr$'[processed] o& +oole$n { initi$ll' &$lse";
turn*processed { initi$ll' either ( or 1";
procedure de,,erw$it(-e*processed);
v$r other*processed;
.e/in
other *= 1 -e;
need[-e] *= true;
while need[other] do .e/in {there is contention"
i& turn = other then .e/in
need[-e] *= &$lse {let other t$,e $ turn";
while turn = other do {nothin/";
need[-e] *=true {re0$ssert -' interest";
end;
end;
end {de,,erw$it";
procedure de,,ersi/n$l{-e*processed";
.e/in
need[-e] * &$lse;
turn *= 1 -e {now it is the other1s turn";
end {de,,$rsi/n$l";
'"( B&4er.=# A+1!rit,$
/aery algorithm can handles critical section problem for n processes. The algorithm is
gi$en below:
do
{
choosin/[i] = true;
nu-.er[i] = -$x(nu-.er[(]2 nu-.er[1]3nu-.er[n01]) 4 1;
choosin/[i] = &$lse;
&or (int 5 = (; 56n; 544)
{
while (choosin/[5] == true
{
7 do nothin/ 7
"
while((nu-.er[5]8=() && (nu-.er[5])5) 6 (nu-.er[i])i))
see re&erence point
{
7 do nothin/ 7
"
"
do critic$l section
nu-.er[i] = (;
do re-$inder section
"
while(true)
Q>. 3,&t &re #e$&,!re#5
Ans: The effecti$e synchroni,ation tools often used to reali,e mutual e!clusion in more
comple! system are called semaphores. A semaphore " is an integer $ariable which can
be accessed only through two standard atomic operations: wait and signal. The definition
of the wait and signal operations are:
9$it(:)* while : 6= ( do s,ip;
:*= : 1;
:i/n$l(:)* :*=:41;
Q1?. E*+&in t,e r!/%"er# !r "!n#%$er# r!0+e$ -it, &+1!rit,$.
Ans: In a producer or consumers problem% a producer (process) produces the
information that is consumed by a consumer (process). 8or e!ample% a compiler may
produce assembly code% which is consumed by an assembler. A producer can produce one
item while the consumer is consuming another item. The producer and consumer must be
synchroni,ed. This problem can be sol$ed either through unbound buffer or bounded
buffer. The algorithm for producer consumer problem is gi$en below:
Shared Data
ch$r ite-;
ch$r .u&&er[n];
se-$phore &ull = (;
se-$phore e-pt' = n;
se-$phore -utex = 1;
ch$r nextp2 nextc;
Producer Process
do
{
produce $n ite- in nextp
w$it(e-pt');
w$it(-utex);
$dd nextp to .u&&er
si/n$l(-utex);
si/n$l(&ull);
"
while(true)
Consumer Process
do
{
w$it(&ull);
w$it(-utex);
re-ove $n ite- &ro- .u&&er to nextc
si/n$l(-utex);
si/n$l(e-pt');
consu-e the ite- in nextc;
"
Q11. E*+&in re&/er# &n/ -riter# r!0+e$ 0. 1i:in1 &+1!rit,$.
Ans: The readers9writers problem is one of the classic synchroni,ation problems. It is
often used to compare and contrast synchroni,ation mechanisms. It is also an eminently
used practical problem. A common paradigm in concurrent application is isolation of
shared data such as a $ariable% buffer% or document and the control of access to that data.
This problem has two types of clients accessing the shared data. The first type% referred to
as readers% only wants to read the shared data. The second type% referred to as the writers
may want to modify the shared data. There is also a designed central data ser$er or
controller. It enforces e!clusi$e writer semantics: if a writer is acti$e then no other writer
or reader can be acti$e. The ser$ice can support clients that wish to both read and write.
The algorithm for the solution of readers and writers problem is gi$en below:
se-$phore -utex = 1;
se-$phore d. = 1;
int re$der_count;
re$der()
{
while(;#<=)
{
down(&-utex);
re$de_count= re$der_count 4 1;
i&(re$der_count==1)
down(&d.);
up(&-utex);
re$d_d.();
down(&-utex);
re$der_count = re$der_count 1;
i&(re$der_count ==(;
up(&d.);
up(&-utex);
re$der_countuse_d$t$();
"
writer()
{
while(;#<=)
{
cre$te_d$t$();
down(&d.);
write_d.();
up(&d.);
"
Q1). E*+&in t,e Dinnin1 P,i+!#!,er# r!0+e$.
Ans: 8i$e philosophers sit around a circular table. ;ach philosopher spends his life
alternati$ely thining and eating. In the centre of the table is a large bowl of rice. A
philosopher needs two chopstics to eat. -nly < chopstics are a$ailable and a chopstic
is placed between each pair of philosophers. They agree that each will only use the
chopstic to his immediate right and left. 8rom time to time% a philosopher gets hungry
and tries to grab the two chopstics that are immediate left and right to him. *hen a
hungry philosopher has both his chopstics at the same time% he eats without releasing his
chopstics. *hen he finished eating% he puts down both his chopstics and start thining
again. The algorithm for dinning philosophers is gi$en below:
>de&ine ?@
>de&ine #%GA;(i) (((i) 4 1) B ?)
>de&ine !=C;(i) (((i)==?D (* (i) 4 1)
t'pede& enu- {;A%?E%?G2 A<?G#F2 =G;%?G" phil_st$te;
phil_st$te s$te[?];
se-$phore -utex = 1;
se-$phore s[?];
7one per philosopher2 $ll( 7
void /et_&or,s(int i) {
st$te[i] = A<?G#F;
while(st$te[i] == A<?G#F) {
H(-utex);
%&(st$te[i] == A<?G#F &&
st$te[!=C;] 8= =G;%?G &&
st$te[#%GA;(i) 8= =G;%?G) {
st$te[i] = =G;%?G;
I(s[i]);
"
I(-utex);
H(s[i]);
"
"
void put_&or,s(int i) {
H(-utex);
st$te[i] = ;A%?E%?G;
i&(st$te[!=C;(i)]==A<?G#F) I(s[!=C;(i)]);
i&(st$te[#%GA;(i)]==A<?G#F)I(s[#%GA;(i)]);
I(-utex);
"
void philosopher (int process) {
while(1) {
thin,();
/et_&or,s(process);
e$t();
put_&or,s();
"
"
Q13. E*+&in t,e #+eein1 0&r0er r!0+e$.
Ans: A barber shop consists of a waiting room with chairs% and the barber room
containing the barber chair. If there are no customers to be ser$ed% the barber goes to
sleep. If a customer enters the barber shop and all chairs are occupied% then the customer
lea$es the shop. If the barber is busy% but chairs are a$ailable% then the customer sits in
one of the free chairs. If the barber is asleep% the customer waes up the barber. The
algorithm for sleeping barber problem is gi$en below:
>de&ine JAG%#: @
t'pede& int se-$phore;
se-$phore custo-ers = (;
se-$phore .$r.ers (;
se-$phore -utex = 1;
int w$itin/ = (;
void .$r.er(void)
{
9hile(;#<=) {
down(&custo-ers);
down(&-utex);
w$itin/ = w$itin/ 1;
up(&.$r.ers);
up(&-utex);
cut_h$ir();
"
"
void custo-er(void)
{
down(&-utex);
i&(w$itin/ 6 JAG%#:)
{
w$itin/ = w$itin/ 4 1;
up(&custo-ers);
up(&-utex)
down(&.$r.ers);
/et_h$ircut();
"
else
{
up(&-utex);
"
"
Q12. 3,&t &re +!"4#5
Ans: 5ocs are another synchroni,ation mechanism. A loc has got two atomic
operations to pro$ide mutual e!clusion. These two operations are Ac#uire and (elease. A
process will ac#uire a loc before accessing a shared $ariable and later it will be released.
A process locing a $ariable will run the following code: !oc,0GcKuire(); critic$l section
$nd !oc,0#ele$se();) The difference between a loc and a semaphore is that a loc is
released only by the process that has ac#uired it earlier.