Introduction to

(1)

Introduction to

Distributed Algorithms and Systems

Achour Most´efaoui

Irisa/Ifsic, Universit´e de Rennes achour@irisa.fr

http://www.irisa.fr/asap/

Master 2 Recherche en Informatique - Octobre 2010 1

Plan

• Basic problems and computing model

• Synchronization: specification and solution design

• Qualities of a distributed algorithm

• A first example: implementing a FIFO channel

• Mutual Exclusion: the come-back

Context (1)

What is a distributed architecture?

• A set of processors

• A communication medium (bus, network, shared memory, etc.)

Context (2)

What is a distributed system?

• A set of processes

• A set of communication services

Above a distributed architecture.

(2)

Context (3) What is a distributed computation?

• Parallel computation:

⋆ Several processors

⋆ One (or more) process(es) per processor

• Communication

⋆ By shared memory, or

⋆ By exchanging messages

Over a distributed system.

Context (4)

Modeling of a distributed computation

• Lattice of global states

• Execution traces (interleavings)

Synchronization Control of the activity of processes.

This means to forbid some interleavings from happening according to the specification of the problem to solve.

There exist several basic synchronization problems.

A non trivial task if the system is asynchronous

• Safety

• Liveness

Asynchronous Distributed System Model (1)

Advantages

• Better fault-tolerance (decentralization of decisions)

• Better efficiency

⋆ Distribution of the load (parallelism)

⋆ Relative Autonomyof the processes (asynchronism)

⇒ loosely coupled: less risk of mutual blocking

(3)

Asynchronous Distributed System Model (2)

Drawbacks

• Process control is harder due to:

⋆ Asynchronism: Impossibility to instantaneously eval- uate predicates on several processes

⋆ Failures: Hardness to maintain the consistency of a computation

⋆ The conjunction of the two: How to distinguish a slow process from a failed process?

Synchronization Problems

Rules and mechanisms to ensure a correct evolution of the processes

• Competition problems:

Each process a priori ”ignores” the existence of the other processes (they are useless for him)

• Cooperation problems:

Each process needs to cooperate with others to do its part of the job

Synchronization Problems

Paradigms

• Competition

⋆ Mutual Exclusion

⋆ Resource Allocation

• Cooperation

⋆ Generalized Rendezvous

⋆ Maintain a global invariant

⋆ Build a global virtual time

A Simple Synchronization Problem: FIFO Channel

Messages sent on a given channel are delivered to the des- tination process in the sending order

• Specification: send(m₁)→send(m₂)⇒rec(m₁)→rec(m₂)

• Which mechanism to use to implement the needed synchronization?

(4)

Qualities of a Distributed Algorithm

• Number of exchanged messages

• Size of needed memory

• Correctness

• Complexity of the design

• . . .

Importance of the Context

The context where the algorithm will be used deeply im- pacts the choice of the solution to a problem.

Example

Mutual Exclusion: Reminder (1)

Access to a shared resource by at most one process at once

• Obtain a write lock on a shared file

• Consistent update of copies of a replicated data

Methodological importance

Mutual Exclusion: the Problem (2)

Algorithmic formulation:

• Each process P_i has a variable state_i∈ {out, asking, in}

• Each P_i can invoke enter cs, exit cs

(5)

Mutual Exclusion: Structure of a Protocol (3)

Structure of a mutual exclusion protocol

For each process P_i

Preamble {state_i =out} enter cs; {state_i =asking}

wait-privilege ; {state_i =in}

Postlude exit cs; {state_i =out}

Mutual Exclusion: Modeling

enter_cs

out asking

in

exit_cs ?

Problem: Transition from the state asking to the state in.

The to transitions enter cs and exit cs are entailed by the process itself.

The transition asking −→ in is triggered by the mutual exclusion protocol.

Mutual Exclusion: Specification

Specification of the solution

• Safety: at most one process in the state in

• Liveness: any process in the state asking becomes in after a finite time (no deadlock, no starvation)

Mutual Exclusion: Classes of Solutions

Two main classes :

• Protocols based on Permissions

Obtain the priviledge ≡ obtain enough permissions Safety: exclusive permissions

• Protocols based on the use of a token Obtain the privilege ≡ have the token Safety: uniqueness of the token

(6)

Token Protocols (1)

• Safety:

Having a unique token ensures to its owner the right to enter the critical section

• Advantage: no need of timestamping

• Problems:

⋆ Ensure liveness

⋆ Loss of the token

Token Protocols (2)

Two strategies

1. Passive: wait for the token (no explicit request). The liveness is ensured if the token reaches all parts of the network (e.g. ring)

2. Active: explicit request sent to the potential owner of the token. The liveness is ensured if any request even- tually reaches the token, and if fairness is guaranteed.

Active Strategy: K. Raymond

The network is logically structured as a tree (static) A dynamic structure is mapped onto the tree structure orientation of the edges

Invariant:

• Each node has a unique father: orientation towards THE sub-tree that contains the token

• The owner of the token is the Root

Protocol of K. Raymond: Example (1)

1

6

2

3

5

4

7

8

9

(7)

1

6

2

3

5

7

8

9

000000 000000 000 111111 111111 111

4

P4 is the owner of the token

P1 requests the token from its father P2, which requests it from its own father P4

6

2

3

5

7

8

9

Transfert of the token from P4 to P1 via P2

000000 000000 000 111111 111111 111

4 1

INVERSION OF THE EDGES

:

Protocol of K. Raymond: Concurrent Requests

Each process plays the role of a proxy node for the account of one of its sons from which it received a Request.

Request from the sons are stored in FIFO order in awaiting queue local to each process.

Empty queue: the process is not asking

Non-empty queue: the process is asking for a request that is stored in its queue.

Reception of the token: the process satisfies the request at the head of the queue.

Protocol of K. Raymond (1)

varstate_i: (out, asking, in) f ather_i: process id;

q_i: queue of process id;

proc enter cs begin

state_i = asking;

if f ather_i=null

then /* p_i has the token */ state_i = in else store i in q_i

if |q_i|= 1 then send request(i) to f ather_i endif endif

end

(8)

proc exit cs begin

state_i=out;

if q_i non empty

then let j be the head of q_i; remove j from q_i; send token to p_j;

f ather_i=j;

if |q_i| 6= 0 then send request(i) to f ather_i; endif endif

end

Upon the reception of request(j) begin

if f ather_i=null

then /* p_i has the token */

if state_i=in

then store j in q_i

else send token to p_j; f ather_i =j endif

else /* p_i does not have the token */

store i in q_i ;

if |q_i|= 1 then send request(i) to f ather_i endif endif

end

Upon the reception of token begin

f ather_i=null;

Let j be the head of q_i; remove j from q_i; if j =i

then state_i =in /* enter the SC */

else send token to p_j f ather_i=j;

if |q_i| 6= 0 then send request(i) to f ather_i; endif endif

end