Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

Note: These concise notes are not a substitution for the

discussions held in class. Always refer to class discussions


and text book.
Distributed systems
• A collection of computers that do not share a common global clock and a common shared
memory that works together to achieve a purpose

• Processes in a distributed system exchange information over the communication channel, the
message delay is unpredictable.

Inherent limitations of a distributed system


Absence of a global clock

Distributed processes cannot rely on having an accurate view of global state, due to physical properties
of a clock and also due to transmission delays. Effectively, we cannot talk meaningfully about global state.
The traditional notions of "time" and "state" do not work in distributed systems. We need to develop
some concepts that are corresponding to "time" and "state" in a uniprocessor system.

Logical clocks
• the "time" concept in distributed systems -- used to order events in a distributed system.

• assumption:

o the execution of a process is characterized by a sequence of events. An event can be of


three types

o the execution of one instruction or of one procedure (local event).

o sending a message is one event (send event), receiving a message is one event(receive
event).

• The events in a distributed system are not total chaos. Under some conditions, it is possible to
ascertain the order of the events. Logical clocks try to catch this.

Lamport's ``happened before'' relation


The ``happened before'' relation ‘->’ is defined as follows:

A -> B if A and B are within the same process (same sequential thread of control) and A occurred before
B.

A -> B if A is the event of sending a message M in one process and B is the event of receiving M by
another process
if A -> B and B -> C then A -> C

Event A causally affects event B iff A -> B.

Events A and B are concurrent (A | | B) if we do not have A -> B or B -> A.

Lamport Logical Clocks


• are local to each process
• do not measure real time
• only measure ``events''
• are consistent with the happened-before relation
• are useful for totally ordering transactions, by using logical clock values as timestamps

Logical Clock Rules


Ci is the local clock for process Pi

• if a and b are two successive events in Pi, then


Ci(b) = Ci(a) + d, where in most cases d = 1
• if a is the sending of message m by Pi, then m is assigned timestamp tm = Ci(a)
• if b is the receipt of m by Pj, then
Cj(b) = max{Cj(b), tm + d}, where in most cases d = 1

Example of Lamport’s Logical Clock:


Drawback of Lamport’s Clock

If a -> b, then C(a) < C(b)

But the opposite is not true, C(a) < C(b) does not imply a -> b

That is, the ordering we get from Lamport's clocks is not enough to guarantee that if two events
precede one another in the ordering relation they are also causally related. The following Vector
Clock scheme is intended to improve on this.

Vector Clocks
• Clock values are vectors
• Vector length is n, the number of processes
• Ci[i](a) = local time of Pi at event a
• Ci[j](a) = time Cj[j](b) of last event b at Pj that is known to happen before local event a

Vector Clock Rules


• if a and b are successive events in Pi, then Ci[i](b) = Ci[i](a) + d, where d=1 normally
• if a is sending of m by Pi with vector timestamp tm
b is receipt of m by Pj then
Cj[k](b) = max{Cj[k](b), tm[k]}

Example of Vector Clock:


Relation between Vector Clock Timestamps

Causal Ordering

Problem of Vector Clock:


Message size increases since each message needs to be tagged with the vector.

Use of Vector Clocks in Causal Ordering of Messages


If send(m1) -> send(m2), then every recipient of both message m1 and m2 must "deliver" m1 before m2.
"deliver" means when the message is actually given to the application for processing.

You might also like