Process A sends a message at local Lamport clock value 5, and process B receives it when its own clock reads 3. After the receive, B updates its clock. Then B executes another local event. What is B's clock value after that local event?
A4 — B just increments from 3.
B6 — B sets its clock to max(3, 5) = 5, then increments to 6 after the receive, then increments again to 7... wait, the question asks after the local event following receive.
C7 — B sets clock to max(3, 5) + 1 = 6 on receive, then increments to 7 on the next local event.
D5 — B adopts the sender's timestamp to stay synchronized.
When B receives a message carrying timestamp 5, it sets its clock to max(local, received) + 1 = max(3, 5) + 1 = 6. This is the clock value for the receive event itself. Then when B executes a subsequent local event, it increments again to 7. The rule ensures that if A's send (clock 5) happened-before B's receive, the receive's clock (6) is strictly greater than 5 — the happens-before ordering is preserved in the clock values.
Question 2 Multiple Choice
Two events have Lamport clock values 10 (event X) and 15 (event Y). What can you reliably conclude about their causal relationship?
AX happened-before Y, because 10 < 15.
BX and Y are concurrent, because their clock values differ by 5.
CIf X happened-before Y, then clock(X) < clock(Y) — but clock(X) < clock(Y) does not prove X happened-before Y; they may be concurrent.
DNothing can be said — Lamport clocks are unreliable for ordering events.
Lamport clocks guarantee: if A happened-before B, then clock(A) < clock(B). But the converse does not hold: clock(A) < clock(B) does not imply A happened-before B. Two processes executing independently will have increasing clocks even with no causal connection. Clock(X) = 10 < 15 = clock(Y) tells us only that Y did not happen-before X — it is consistent with X happening-before Y OR with X and Y being concurrent. To detect concurrency precisely, you need vector clocks, which track one counter dimension per process.
Question 3 True / False
If event A has a strictly smaller Lamport timestamp than event B, then A is expected to have happened-before B.
TTrue
FFalse
Answer: False
This is the most important misconception about Lamport clocks. The guarantee runs only one direction: happened-before implies lower timestamp. The converse fails. Two concurrent events on separate processes will accumulate increasing timestamps independently — A's clock can be lower than B's simply because A's process has executed fewer events, not because of any causal link. Lamport timestamps can detect when events are NOT concurrent (if B's timestamp ≤ A's, then B cannot have happened-before A), but they cannot confirm causality from timestamp order alone.
Question 4 True / False
Logical clocks are designed to detect and track the 'happens-before' causal relationship between distributed events, not to measure elapsed physical time.
TTrue
FFalse
Answer: True
This is the central insight of logical clocks. Physical wall-clock time cannot be trusted for ordering events across distributed nodes because clocks drift and cannot be perfectly synchronized. Lamport's key insight was to replace physical time with a causal model: what matters is not when events occurred on a global clock, but whether one event could have influenced another through message passing or local execution ordering. The happens-before relation captures this precisely. Logical clocks implement a counter discipline that faithfully tracks this causal structure, regardless of physical timing.
Question 5 Short Answer
Why is wall-clock time insufficient for ordering events in a distributed system, and what specific property do logical clocks provide instead?
Think about your answer, then reveal below.
Model answer: Wall-clock time is insufficient because each node maintains its own clock and clocks inevitably drift apart — they cannot be perfectly synchronized. A timestamp on node A at 10:00:00.003 may actually refer to an event that occurred after an event timestamped 10:00:00.005 on node B, because A's clock runs fast. Logical clocks replace physical time with a causal counter discipline that tracks the happens-before relation: if event A could have causally influenced event B (because A executed before B on the same process, or A sent a message that B received), then clock(A) < clock(B). This gives a partial order consistent with causality, which is what distributed algorithms actually need.
The deeper point is that 'when' an event happened (in absolute physical time) is often irrelevant to correctness; what matters is 'could this event have been affected by that one?' Logical clocks answer exactly that question.