Specifying distributed computation
Why do we need these?
Don’t we already know a lot about programming?
Well, you need to capture the notions of
atomicity, non-determinism, fairness etc. These
concepts are not built into languages like JAVA,
C++ etc!
Syntax & semantics:
guarded actions
Guarded action
<guard G>  <action A> is equivalent to
if G then A
Syntax & semantics: guarded
actions
Three types of constructs:

Sequential actions
S0; S1; S2; . . . ; Sn

Alternative constructs
if . . . . . . . . . . fi

Repetitive constructs
do . . . . . . . . . od
The specification is useful for representing
abstract algorithms, not executable codes.
Syntax & semantics
Alternative construct
if


…

fi
G 0  S0
G 1  S1
G 2  S2
G n  Sn
When no guard is true, skip (do nothing). When multiple guards
are true, the choice of the action to be executed is completely
arbitrary.
Syntax & semantics
Repetitive construct
do

.

od
G 1  S1
G 2  S2
G n  Sn
Keep executing the actions until all guards are false and the
program terminates. When multiple guards are true, the choice
of the action is arbitrary.
An example
program
uncertain;
define
initially
do
x<4

x=3
od
x :
x=0


integer;
x := x + 1
x := 0
Question. Will the program terminate?
Here fairness becomes an important issue
Adversary
Distributed computation can be viewed
as a game between the system and an
adversary. The adversary comes up with
schedules to challenge the system.
Non-determinism
Non-determinism is abundant in the real world.
Determinism is a special case of non-determinism.
(Program for a token server - it has a single token}
repeat
if (req1 and token) then give the token to client1
else if (req2 and token) then give the token to client2
else if (req3 and token) then give the token to client3
forever
Now, assume that all three requests are sent simultaneously.
Client 1 always gets the token!
Atomicity (or granularity)
Atomicity = all or nothing
Atomicity = indivisible actions
do red  x:= 0 {red action}
 blue  x:=7 {blue action}
od
Regardless of how nondeterminism
is handled, we would expect that
the value of x will be an arbitrary
sequence of 0's and 7's.
Right or wrong?
x
Atomicity (or granularity)
Does hardware guarantee any
form of atomicity? Yes!
Transactions are atomic by
definition (in spite of process
failures). Also, critical section
codes are atomic.
We will assume that G  S is
an atomic operation
if x ≠ y  y:= x fi
x
y
if x ≠ y  y:= x fi
Atomicity
{Program for P}
Define b: boolean
initially b = true
do b  send msg m to Q
 ¬empty(R,P) receive msg;
b := false
od
Suppose it takes 15 seconds to
send the message. After 5 seconds,
P receives a message from R. Will it
stop sending the remainder of the
message?
NO.
R
P
b
Q
Fairness
Defines the choices or restrictions on the
scheduling of actions.



Unconditional fairness
Weak fairness
Strong fairness
Fairness
Program
test
define x : integer
{initial value unknown}

do


od

true
x=0
x=1



x:=0
x:=1
x:=2
An unfair scheduler may never
schedule the second (or the
third actions). So, x may always
be equal to zero.
An unconditionally fair
scheduler will eventually give
every statement a chance to
execute without checking their
eligibility. (Example: process
scheduler in a multiprogrammed
OS.)
Weak fairness
Program test
define x : integer
{initial value unknown}
do
true
 x:=0

x=0  x:=1

x=1  x:=2
od


A scheduler is weakly fair,
when it eventually executes
every guarded action whose
guard becomes true, and
remains true thereafter
A weakly fair scheduler will
eventually execute the
second action, but may never
execute the third action.
Why?
Strong fairness
Program
test
define x : integer
{initial value unknown}
do
true
 x:=0

x=0  x:=1

x=1  x:=2
od


A scheduler is strongly fair,
when it eventually executes
every guarded action whose
guard is true infinitely
often.
The third statement will be
executed under a strongly
fair scheduler.