Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A timestamp is a clock reading, not proof that one event caused another. Machines can disagree about physical time; Lamport logical clocks instead ensure that causally connected events receive increasing counters. They help order events, but they do not tell you the UTC time or how much time passed.
Why wall-clock timestamps can put events in the wrong order
Each machine’s wall clock is a local estimate of physical time. Clock skew, drift, synchronization delays, and clock adjustments can make two machines report different times for events that are causally related.
Imagine process A records an event at 10:00:00.100 and sends a message. Process B receives it and records the consequence at 10:00:00.090. If B’s clock lags enough, sorting those log entries by their timestamps makes the consequence appear to precede its cause. These times are illustrative, not a measured clock-skew result.
Wall-clock time is still useful for logs, deadlines, and human-readable dates. The mistake is treating a clock reading as proof of causal order. Google’s Spanner documentation describes how a lagging local clock could assign a later transaction an earlier timestamp, potentially causing a snapshot to omit an earlier completed transaction.
#1 Best Overall
What “happened before” means
Distributed systems need to distinguish events that could have influenced one another from events that are independent. The happened-before relation captures that distinction:
- Events on the same process are ordered by that process’s execution.
- Sending a message happens before receiving it.
- The relation is transitive: if A happens before B, and B happens before C, then A happens before C.
Events linked by this relation are causally ordered. Events with no such link are concurrent in this model: neither is known to have influenced the other. Causality is therefore a partial order, not necessarily a single timeline.
Rank #2
How Lamport logical clocks work
A Lamport clock is a counter maintained by each process. It advances according to local events and message exchange, rather than attempting to track seconds or UTC. Lamport’s 1978 paper states the clock condition: if event A happened before event B, then L(A) < L(B).
- Before each local event, increment the process’s counter. Use the resulting value as that event’s logical timestamp.
- When sending a message, attach the current counter. The receiver needs this value to account for the sender’s event.
- When receiving a message stamped
t, set the local counter tomax(local counter, t), then increment it. Timestamp the receive event with the incremented value.
Because a message’s receive event gets a counter greater than its send event, and local events increase their process’s counter, causally connected events receive increasing timestamps. The original algorithm and its ordering properties are in Lamport’s paper, “Time, Clocks, and the Ordering of Events in a Distributed System”.
Rank #3
What logical timestamps prove—and what they do not
If L(A) < L(B), it does not follow that A caused B. A lower Lamport timestamp is consistent with causality, but does not establish it. Independent processes can have different counter values even when their events are concurrent.
Lamport clocks also do not reveal UTC time or elapsed duration. A counter of 12 is not a time of day, and the difference between counters 12 and 20 does not mean eight seconds—or any fixed interval—passed. Use physical clocks when a system needs externally meaningful times, and make the synchronization and uncertainty assumptions explicit.
Rank #4
When an algorithm needs a total order
Some protocols need every event to sort before or after every other event, even when those events are concurrent. To create a deterministic total order, compare the pair (logical timestamp, process ID) lexicographically. The process ID breaks ties when counters match; implementations should use stable, unique identifiers.
This convention extends the causal order: if A happened before B, A still sorts first. But when concurrent events are ordered by their process IDs or different counters, that ordering is a protocol choice—not evidence that one event really happened first. Lamport discusses this extension in the 1978 paper, including its use in distributed mutual exclusion.
How Spanner’s TrueTime differs from a Lamport clock
Google Cloud’s Spanner documentation describes TrueTime as a clock that supplies an interval of possible physical times, rather than a single perfectly certain instant. Spanner uses its guarantees when assigning transaction timestamps to support external consistency: when generation of one timestamp finishes before generation of another begins, the later timestamp is guaranteed to be greater.
The distinction is fundamental. TrueTime addresses bounded uncertainty about physical time in a particular database architecture. Lamport clocks use counters and message exchange to preserve causal ordering. A Lamport clock does not give Spanner’s real-time guarantees, and an ordinary wall clock does not inherit TrueTime’s guarantees.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
