Representing distributed algorithms Why do we need these? Dont we - - PowerPoint PPT Presentation

Representing distributed algorithms

Why do we need these? Don’t we already know a lot about programming?

• We need to capture the notions of atomicity,

non-determinism, fairness etc.

• The program should be concise

Syntax & semantics: guarded actions

<guard G> → <action A> is equivalent to if G then A Motivation: think message passing or event based systems

Syntax & semantics: guarded actions

• 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 G1  S1 ฀ G2  S2

…

฀ Gn Sn fi When no guard is true, skip (do nothing). When multiple guards are true, the choice of the action to be executed is completely arbitrary (or non- deterministic).

Syntax & semantics

Repetitive construct do G1 S1 ฀ G2  S2 . ฀ Gn  Sn

• d

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.

• For most programs, we

will utilize this construct.

• For brevity, we will
• mit do/od

Example: graph coloring

1 1 ∃j ∈ neighbor(i): c(j) = c(i) → c(i) := 1-c(i) Will the computation terminate?

Example: graph coloring continued

∃j ∈ neighbor(i): c(j) = c(i) → c(i) := 1-c(i) Instead of writing c(j) = c(i) → c(i) := 1-c(i) We will write

An example

program uncertain; define x : integer; initially x = 0 do x < 4  x := x + 1 ฀ x = 3  x := 0

• d
• Question. Will the program terminate?

(Here fairness becomes an important issue)

The adversary

A distributed computation can be viewed as a game between the system and an adversary. The adversary comes up with feasible schedules to challenge the system, and a correct algorithm must have an adequate response to meet the challenge.

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! 1 2 3 Token server

Atomicity (or granularity)

Atomic = all or nothing Atomic actions = indivisible actions do red → x:= 0 {red action} ฀ blue → x:=7 {blue action}

• d

Regardless of how nondeterminism is handled, we would expect that the value of x will be an x The answer depends on atomicity

Atomicity

{Program for P} define b: boolean initially b = true do b  send msg m to Q

฀ ¬ empty(R,P) receive msg;

b := false

• d

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.

P Q R

b

Fairness

Defines the choices or restrictions on the scheduling

• f actions. No such restriction implies an

unfair scheduler. For fair schedulers, the following types of fairness have received attention: – Unconditional fairness – Weak fairness – Strong fairness

Fairness

Program test define x : integer {initial value unknown} do true  x : = 0 ฀ x = 0  x : = 1 ฀ x = 1  x : = 2

• d

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

• d
• 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

• d
• 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. Why?

Fairness Requirement for our Class

• Most programs considered in our class would

utilize weak fairness or unconditional fairness

– Weak fairness implies every enabled action is guaranteed to execute at some time – Unconditional fairness gives every action a chance to execute;

• If not enabled (disabled) at the time, its execution has no

effect.

• Why?