Dissection · Lamport, 1978

Anatomy of Lamport Clocks

Time, Clocks, and the Ordering of Events, dissected: an execution laid out in 3D with its logical clocks, vector clocks, every pair of events, the mutual exclusion algorithm and a physical-clock synchroniser, all computed live and checked against what really happened before what.

PaperLamport, CACM 21(7), 1978

Modelan execution, live

Reading27 min · 29 steps

Published2026-10-16

01Overview

Why "before" is not a number

In 1978 Leslie Lamport argued that in a distributed system it is sometimes impossible to say that one of two events occurred first [1]. What "before" can mean there is a partial order; and a counter on every machine, with one rule for messages, extends it to a total order that every machine can compute alone.

What you are looking at is that argument, built out of numbers. Each column on the table is a process. Time runs up the table. Every event is a pair of blocks: the left one is its Lamport clock, a single cell whose height is the value, and the right one is its vector clock, one cell for each process. The curved links are messages. Further up the table are every pair of events as matrices, the mutual exclusion algorithm with one request queue per process, and a set of physical clocks being synchronised.

Nothing here is a drawing of data. The execution, the clocks, the matrices, the queues and the skew between clocks are all computed in this page, from the rules in the paper, and test.mjs checks them against an independent computation of what really happened before what. The visual grammar, values as blocks of cells that you can hover, follows Brendan Bycroft's LLM Visualization [2].

How to use this page

Scroll the article, or use ← →. Drag the stage to orbit, scroll on it to zoom; O shows the whole machine and R replays a step's animation. Type paper or a number in the input to change the execution, and every block, figure and number is recomputed.

Go deeper: Clocks and ordering in practice · Clock and ordering

02Overview

One execution on the table, a thousand in the research desk

The paper draws one execution, its Figure 1, and reasons about all of them. The default input, paper, is that figure transcribed: processes P, Q and R, events $p_{1} \dots p_{4}$ , $q_{1} \dots q_{7}$ , $r_{1} \dots r_{4}$ and six messages. Any number is the seed of a random execution of four processes and 28 events. This page holds .

A model of this kind is exactly checkable, because the thing it simulates is a definition. . The truth for each pair is computed from the graph of events and messages alone, and every clock on the stage is compared against it. The research desk at the end repeats the measurements over seeded executions of 3 to 8 processes; what it finds is evidence about the mechanism, not a forecast for a system with thousands of nodes.

03The partial order

A process is a line of events with a fixed order

Lamport's system is a collection of processes, each a set of events with an a priori total ordering. What an event is depends on the application: [1] allows anything from a single machine instruction to the execution of a subprogram, and notes that the choice changes the ordering of a process's receives, since interrupts need not be handled in the order they occur.

On the stage each process is a column, and its events stand in the order they occurred, earliest at the bottom, named after the paper: $p_{1}, p_{2}, \dots$ for process P. Inside one process there is never a doubt about which event came first. The trouble starts when two processes have to agree.

Go deeper: Message ordering · Distributed systems

04The partial order

A message is two events, and the only thing that crosses a column

[1] counts sending and receiving as events of their own. The links on the stage run from each sending event to the matching receive. Lamport allows several messages to be sent in a single event, but assumes a receive does not coincide with any other send or receive; the generator here follows that, and Figure 1's $q_{1}$ is an event that sends two messages. A red stub, if one appears, is a message that had not arrived when the execution ended.

The paper is careful about delivery. In general it observes that messages may be received out of order, and the stage draws them as they are. Only the mutual exclusion algorithm, later, needs the stronger assumption that each channel keeps its order, which the paper states there.

Go deeper: Message ordering · Exactly-once semantics

05The partial order

"Happened before" is reachability in the graph of events

Lamport defines it without a clock. The relation → on the set of events of a system is the smallest relation satisfying three conditions: events in one process are ordered as the process runs them; a send comes before its receipt; and the relation is transitive.

a \to b ⟺ there is a path from a to b along process steps and messages

That is a graph statement: $a \to b$ means that you can walk from $a$ to $b$ , going up the columns and along messages, never against them. The paper's reading is causal. $a \to b$ means that it is possible for $a$ to causally affect $b$ . The amber events on the stage are the ones reachable from the focused event; the rest are not touched by it. .

The relation is an irreflexive partial ordering. The paper also notes the kinship with relativity [3][4]: there, events are ordered by messages that could be sent; here only messages that were sent count, so a system can be judged from the events that occurred.

Go deeper: Causal consistency · Version vector

06The partial order

Two events are concurrent when neither can have heard of the other

Two distinct events are concurrent if neither happened before the other. The paper's example is in Figure 1: $p_{3}$ and $q_{3}$ . Even though the figure draws $q_{3}$ lower, which would be an earlier physical time, process P cannot know what Q did at $q_{3}$ until a message says so. .

This is the whole difficulty in one picture. "Concurrent" does not mean "at the same time", and it does not mean that the order is unknown; it means that in this system there is no order. [1] notes that people run into trouble because they are not fully aware of this, and the closing line of the paper repeats it: in a distributed system, the order in which events occur is only a partial ordering.

Go deeper: Causal consistency · CRDTs · Consistent prefix read

07Logical clocks

A clock is a number on each event, and it must never contradict the arrows

A logical clock is, in the paper's words, a way of assigning a number to an event, implementable by counters with no actual timing mechanism. The correctness condition cannot mention physical time, so it is stated on the order alone.

Clock Condition: for any events a, b : a \to b \Rightarrow C (a) < C (b)

The paper gives it as if $a \to b$ then $C (a) < C (b)$ . It splits into two local checks: within a process the clock increases (C1), and a message is received at a larger value than it was sent at (C2). The paper draws the idea as tick lines: if two consecutive events have clock values 4 and 7, the ticks 5, 6 and 7 occur between them, and a dashed line joins all events with the same value, so that every process line is crossed by tick lines and every message line crosses one.

The orange dashes on the stage are those tick lines for this execution, Figure 2 of the paper. They are crooked, because processes advance at different rates. Straightening them gives Figure 3, which the paper presents as an equally valid picture of the same events, and the toggle in the figure of the previous step does exactly that: it lays the same execution out by clock value.

On this execution

, over every pair.

Go deeper: Clocks and ordering in practice · Hybrid logical clock

08Logical clocks

Rule one: tick between any two events

The first implementation rule makes condition C1 hold. IR1: each process increments its clock between any two successive events. Nothing else is needed within a process, and the clock is a bare counter: the focused column on the stage is one process's clock, rising by at least one at every event.

Hover a clock cell to see how it was reached. A receive event is the only kind whose value is not simply "the previous value plus one"; that is rule two.

09Logical clocks

Rule two: a receive jumps past the timestamp it was sent with

Condition C2 needs the clocks of different processes to meet. Each message carries a timestamp equal to the time at which it was sent, and the receiver obeys the second rule, IR2: (a) the sender stamps the message with its clock value at the sending event, (b) on receipt the receiver sets its clock greater than or equal to its present value and greater than the timestamp.

C_{j} (receive) = max (C_{j} (previous) + 1, T_{m} + 1)

The $+ 1$ on the first term is IR1 and the second term is IR2(b). . IR1 and IR2 suffice to guarantee a correct system of logical clocks, and that is all the algorithm is: one integer per process, one integer per message, and a maximum.

Go deeper: Hybrid logical clock · Time-ordered identifier

10Logical clocks

If clock values order the arrows, they also order things the arrows do not

The Clock Condition runs one way. The paper is explicit that the other way cannot hold: the converse would imply that any two concurrent events must occur at the same time, and in Figure 1 $p_{2}$ and $p_{3}$ are both concurrent with $q_{3}$ while $p_{2} \to p_{3}$ , so $C (p_{2}) < C (p_{3})$ forces them to differ.

The stage shows what that means for a reader who takes $C (a) < C (b)$ as " $a$ before $b$ ". The three matrices have one cell per pair: the truth from the graph, the claim from the clocks, and where they differ. Amber cells are pairs the clock values separate although neither event can affect the other. The blue cells, where the graph has an arrow and the clocks do not, would break the Clock Condition: there are none. . .

The paper does not measure how far this goes, and the research desk below does. .

Go deeper: Causal consistency · Linearizability

11Logical clocks

Break ties by process number and every pair has an order

A total order is what an algorithm wants, and the clocks supply one. The paper orders the events by clock value and, to break ties, uses any arbitrary total ordering of the processes: $a \Rightarrow b$ when $C_{i} (a) < C_{j} (b)$ , or when the values are equal and $P_{i}$ comes before $P_{j}$ .

a \Rightarrow b ⟺ C (a) < C (b) or (C (a) = C (b) and P (a) < P (b))

The right-hand column on the stage is that list for this execution. It completes the happened-before partial ordering to a total ordering: wherever $a \to b$ , $a$ is above $b$ in the list. But the ordering depends on the system of clocks and is not unique; only the partial ordering is uniquely determined. .

Every machine can compute this order from what it has seen. That is its use, and the next steps use it. It is also exactly why it can mislead, because the order says something about concurrent pairs that the system does not know.

Go deeper: Consensus protocols · Replication

12Using the order

Sharing one resource, and why a central scheduler is not enough

The paper uses the total order to solve mutual exclusion. A fixed set of processes shares one resource; the algorithm must grant it so that a process which has been granted the resource must release it before it can be granted to another (I), requests are granted in the order in which they are made (II), and if every holder eventually releases, every request is eventually granted (III).

The obvious answer fails. A central scheduling process that grants requests in the order they are received will not work, unless additional assumptions are made. The paper's scenario is the table below: P1 asks the scheduler P0 for the resource and then sends a message to P2; P2's own request, sent after that message, reaches P0 first, and condition II is violated.

The stage shows three request queues, one per process, and the clocks and who holds the resource. Nothing is central.

Go deeper: Distributed locks in practice · Distributed locking · Two-phase locking

13Using the order

Five rules, each a single event, and one private queue per process

Each process keeps its own request queue, never seen by any other process. The paper assumes channels deliver in order, every message is eventually received, and any process can send directly to any other. Initially every queue holds one request, from the process $P_{0}$ that holds the resource, with a timestamp lower than any clock. Then:

Request. To request the resource, $P_{i}$ sends the request to every other process and puts it on its own queue.
Receive a request. A process places it on its queue and sends a timestamped acknowledgment.
Release. To release, $P_{i}$ removes its request from its queue and sends a timestamped release message to every other process.
Receive a release. The receiver removes the matching request from its queue.
Grant. $P_{i}$ is granted the resource when two conditions are satisfied: its request is first in its queue under $\Rightarrow$ , and it has received a message from every other process timestamped later than its request.

The stage plays the first half of a run of this page's simulation: watch the queues, the clocks, and which link is carrying a message. The paper adds two optimisations in footnotes (an acknowledgment is unnecessary if the receiver has already sent a later-stamped message, and the second grant condition may be weakened for some pairs of processes); the simulation implements the plain rules and does not use them. Both grant conditions are tested locally, which is the point.

Go deeper: Replication · Write-ahead log

14Using the order

Grants come out in timestamp order without anyone coordinating them

This is the complete simulated run: two rounds of requests from three processes, every delay drawn at random but each channel kept in order. The first grantee is whoever's request is first in the order, once the earlier holder has released and every process has answered. The stage's last column of queues shows the final state. .

The paper's argument for correctness is short: condition (ii) of rule 5, with in-order channels, guarantees the grantee knows every earlier request; rules 3 and 4 are the only ones that delete requests, giving condition I; condition II follows from the fact that $\Rightarrow$ extends $\to$ ; and rule 2 makes condition (ii) eventually true, with rules 3 and 4 making (i) eventually true, which gives III. The checks in test.mjs do not rely on that argument: they measure the three conditions on 360 simulated runs.

Go deeper: Leader election · Raft

15Using the order

Condition I and II are measured on global time and on vector clocks, not assumed

Condition I is checked against global time: the intervals during which a process holds the resource must not overlap. Condition II is checked against causality: if one request happened before another (by vector clocks, which the algorithm itself never reads), it must be granted first. Condition III is checked by counting grants. For every run, over 3, 4 and 5 processes and one and two rounds, there were no overlaps, no grants out of causal order and no ungranted requests.

The cost is also countable. Each request sends a request and an acknowledgment to every other process and later a release, which is $3 (N - 1)$ messages per use of the resource: six for three processes. The paper does not give that figure; it is measured here, and the test confirms it exactly (request, ack and release counts each equal $N - 1$ per entry).

Go deeper: Quorum · Exactly-once semantics

16Using the order

The same trick implements any synchronisation, and halts if one process stops

The queue of requests is a special case. In general the synchronisation is specified as a State Machine: a set of commands, a set of states and a function from a command and a state to a new state. The mutual exclusion queue is the state, request and release are the commands. Each process simulates the machine on the commands issued by all processes, and because all of them order commands by $\Rightarrow$ , there is no central synchronizing process or central storage. The canon entry for this page names this as where state-machine replication starts.

The price is stated with the same directness. The algorithm needs every process: the failure of a single process makes it impossible for any other process to execute commands, halting the system. The paper's remark about failure is more interesting than the failure itself: without physical time there is no way to distinguish a failed process from one which is just pausing between events. It points to a method that tolerates failures [5], and promises a future paper that extends the approach to any synchronization problem. Neither is read for this page.

Go deeper: Consensus protocols · Raft · Replication

17Time and anomalies

The order can disagree with the order the users perceive

The total order is built from events inside the system. The paper's example of what that misses: a person issues request A on one computer and then telephones a friend in another city to issue request B on a different one. It is quite possible for request B to receive a lower timestamp and be ordered before request A, because the system has no way of knowing that A preceded B, since that precedence information is based on messages external to the system. .

The paper offers two remedies. The first puts the burden on the user: the person who issued A could receive its timestamp from the system and tell their friend to stamp B later. The second needs clocks that respect events outside the system, which is the next step. The research desk measures how often the anomaly occurs, a number the paper does not give.

Go deeper: Untrusted client timestamp · Wall-clock schedule hazard

18Time and anomalies

A clock that respects the outside world has to be a physical one

Let $S$ be the system's events and $\underline{S}$ the larger set that includes external events such as the phone call, with $⇝$ for happened-before on that larger set. The wanted condition is the Strong Clock Condition: for any events $a, b$ of the larger set, $a ⇝ b$ implies $C (a) < C (b)$ . It is stronger than the ordinary condition because the arrow is stronger, and it is not in general satisfied by our logical clocks.

The paper's way out is physical clocks. In one of its more famous asides, one of the mysteries of the universe is that physical clocks, running independently of one another, can satisfy the Strong Clock Condition. What that needs is quantitative: the next three steps.

The stage shows the same execution's tick lines again. In the Strong Clock Condition they would be true time, and the external phone call would cross a tick line like any message.

Go deeper: Google Spanner TrueTime · Clock drift

19Physical clocks

Two requirements: run at nearly the right rate, stay near each other

Physical clocks are continuous functions $C_{i} (t)$ of true time. The paper asks for two things. PC1: there is a constant $κ ≪ 1$ with $∣ d C_{i} (t) / d t - 1 ∣ < κ$ , and for typical crystal controlled clocks $κ \leq 1 0^{- 6}$ . PC2: all pairs satisfy $∣ C_{i} (t) - C_{j} (t) ∣ < ϵ$ , which is needed because it is not enough for the clocks individually to run at approximately the correct rate; they must be synchronized.

The stage shows five simulated clocks as offsets from true time, $C_{i} (t) - t$ , through 160 time units. They start up to 6 units apart, run at the extremes of the drift allowed, and exchange messages. Blue means a clock is behind true time, amber ahead. This page uses $κ = 0.01$ so that the drift is visible, which is four orders of magnitude worse than the paper's typical crystal.

Go deeper: Clock drift · Invalid clock at boot

20Physical clocks

The same two rules, with physical time in them

The algorithm is the earlier one with the numbers replaced by physical readings. IR1′: a clock that does not receive a message runs forward, $d C_{i} / d t > 0$ . IR2′: a message carries $T_{m} = C_{i} (t)$ and the receiver sets $C_{j} (t^{'}) = max (C_{j} (t^{'} - 0), T_{m} + μ_{m})$ , where $μ_{m}$ is a known minimum delay: the receiving process knows some minimum delay. The paper stresses that a clock is only ever set forward, never back, because setting it back could break condition C1, and the rules are specialisations of IR1 and IR2, so the Clock Condition still holds.

The matrix beside the offsets is the skew between each pair of the five clocks at the end of the run. It has a zero diagonal, and the largest off-diagonal entry is what the theorem bounds. The operation is the one from IR2: a maximum.

Go deeper: Hybrid logical clock · Google Spanner TrueTime

21Physical clocks

How far apart can the clocks drift? At most about d(2κτ + ξ)

The processes form a directed graph with an arc for each communication line; its diameter $d$ is the smallest number such that any two processes are joined by a path of at most $d$ arcs. A message is sent over each arc at least every $τ$ seconds, with a minimum delay $μ$ and an unpredictable part below $ξ$ . The paper's theorem:

ϵ \approx d (2 κ τ + ξ) for all t ≳ t_{0} + τ d, assuming μ + ξ ≪ τ

Then PC2 is satisfied with $ϵ \approx d (2 κ τ + ξ)$ , under a strongly connected graph of processes with diameter $d$ obeying IR1′ and IR2′. It also bounds the time to synchronise from a cold start. The proof is surprisingly difficult and in an appendix; the paper adds that the requirement that clocks are never set backwards seems to distinguish its situation from ones previously studied, and believes the theorem to be a new result, citing a survey of earlier physical synchronisation [6].

The right-hand columns on the stage are the largest skew at each sample time and the bound, which includes one time step of simulation granularity. . Try the figure: shrink $τ$ , raise $κ$ , or increase $ξ$ , and the skew and the bound move together.

Go deeper: Clock drift · Google Spanner TrueTime

22The fix

To tell concurrent from ordered, keep one counter for each process

Lamport's clock collapses the whole history of an event into one integer, and one integer cannot say which events are in the past. The fix, introduced independently by Fidge [7] and by Mattern [8], keeps a counter for every process. Each process $P_{i}$ keeps a vector $V$ of $N$ integers. At every event it increments its own entry, $V [i] + = 1$ ; a message carries the sender's vector; the receiver first takes the entrywise maximum of its vector and the message's.

a \to b ⟺ V (a) \leq V (b) entrywise and V (a) \neq = V (b)

The right block of every event on the stage is its vector. Entry $j$ of $V (a)$ is the number of events of process $j$ that $a$ has heard of, directly or through others, so two vectors where neither dominates the other come from events that could not have heard of each other: concurrent. The price is $N$ integers on every message instead of one. Neither of the two papers was read for this page; the rule above is the standard statement of it, and every vector on the stage is checked against the graph, which is the proof that matters here.

Hover a vector cell: it says which process it counts and whether it is the event's own counter.

Go deeper: Version vector · CRDTs · Multi-leader replication

23The fix

The vector test agrees with the graph on every pair

The fourth matrix is the vector test, $V (a) < V (b)$ , side by side with the truth. They are the same matrix. , and the same holds in every one of the 600 random executions of test.mjs with 3 to 6 processes and 20 to 40 events, and in the 210 executions of the first experiment below.

Notice what the vector test also does that the Lamport clock cannot: it returns three answers, not two. For a pair it can say " $a$ before $b$ ", " $b$ before $a$ " or "neither". That third answer is what the first experiment shows Lamport clocks cannot give.

Go deeper: Version vector · Causal consistency · Consistency models

24Research desk

E1 · What does a Lamport order say about the pairs it cannot know?

Claim

The converse of the Clock Condition cannot hold [1], so clock values order some pairs that the system does not. The paper does not say how many.

Hypotheses

H1a At every message rate at least 75% of concurrent pairs have different clock values. H1b The precision of "smaller means before" rises by at least 10 points as messages get denser, yet stays below 95% for every rate up to 0.5. H1c Vector clocks make zero errors.

Design

5 processes, 60 events, send probability from 0.05 to 0.9 in 7 steps, 30 seeds per step (210 executions). Written before the first run in research/README.md; the verdict rules are in research/summarise.mjs.

The sweep above runs the same measurement on your own choice of processes and events, with 20 seeds per point, in your browser.

Go deeper: Multi-seed reporting and run-to-run variance · Monte Carlo methods

25Research desk

E2 · Does the fix need every entry?

Claim

Each process gets an entry of its own [7][8]. A lower bound is reported in the literature [9], not read here; this experiment illustrates it without proving or checking it.

Hypothesis

H2 The error rate falls as the number of entries

k

grows, and only

k = N

is error-free: fewer than 10% of executions are error-free for any

k < N

Design

Process

i

uses entry

i mod k

of a

k

-entry vector, merged by maximum.

k = 1

is exactly Lamport's clock (checked in test.mjs);

k = N

is the vector clock.

N = 4

and

N = 8

, 80 events, send probability 0.35, 30 seeds per arm.

The stage shows the case $k = N - 1$ for this execution: the matrix marked amber has a cell for every pair that the folded vector gets wrong.

Go deeper: Version vector · CRDT replica-ID inflation

26Research desk

E3 · How often does the phone call go wrong?

Claim

"It is quite possible for request B to receive a lower timestamp and be ordered before request A."

Hypotheses

H3a At send probability 0.05 and a delay of 10 steps, at least 20% of pairs with nothing in the system between them are ordered the wrong way. H3b More messages make this rarer: the rate at 0.9 is at least 2 points lower than at 0.05.

Design

5 processes, 80 events, four send probabilities, four delays, 30 seeds each. B is on another process, at least

L

steps after A, with no path from A to B in the system. Wrong means

C (B) < C (A)

, ties to the lower process number.

The stage highlights, in this execution, the largest case: an event and a later one on another process that the total order puts first. .

Go deeper: Untrusted client timestamp · Time-ordered identifier

27Research desk

E4 · Is the theorem's bound ever reached?

Claim

The skew is at most

d (2 κ τ + ξ)

after

t_{0} + τ d

, approximately.

Question (exploratory)

Added after test.mjs had printed the largest skew-to-bound ratio of its grid, so it is not pre-registered. Is the bound ever exceeded, and how close do random runs come?

Design

5 clocks, ring and complete graph,

κ \in {0.001, 0.01}

τ \in {5, 10, 20}

μ = ξ = 0.5

, 24 seeds per row. The drift alternates randomly between the extremes, not adversarially.

28Research desk

What this leaves open

Unequal machines. The exploratory arm of E3 used one busy process with a single choice of weights. How does the wrong-order rate scale with the ratio of activity, and is there a message rate at which it vanishes?
Which concurrent pairs matter? E1 counts every pair. A program only compares some, for example two requests for the same lock. Weighting pairs by a workload, and re-measuring, would turn S into a number about a system.
Partial vectors. E2 folds entries by process number. Other assignments, with entries shared between processes that rarely run concurrently, may be accurate where this one is not; whether any such scheme is exact for a given execution is what the literature on the size of vector clocks addresses [9], and this page has not read it.
The exact bound. E4 uses the paper's approximate $d (2 κ τ + ξ)$ . Comparing against the exact relation (11), and against adversarial rather than random drift, would show how much of the gap in E4 is looseness of the bound and how much is the benign drift.
Failures. The paper says the algorithm halts if one process stops. Adding crashes to the mutual exclusion simulation, and measuring how long the others wait before a timeout would put the paper's remark about physical time and failure into numbers.

29Research desk

What was read, what was not, and how to check it

The primary source, the ACM printing of [1], was read in full: text, footnotes, appendix and the three figures. Every quote in the fact ledger was checked against its text; six passages, where the PDF's text layer garbles symbols and subscripts, were checked against the page images, and the ledger says which. Figure 1 was transcribed from the page image into engine.js, and test.mjs confirms the paper's own sentences about it.

Not read in this run, and cited only for what the paper or the literature says about them: Fidge's and Mattern's papers on vector clocks [7][8], Charron-Bost's [9], the paper's own sources [3][4][6], and the companion paper on tolerating failures [5]. The vector clock rule used here is its standard statement, and it is validated against the event graph on every execution rather than on trust.

Everything is reproducible from engine.js (the model), test.mjs (8,364 checks), research/README.md (the pre-registration), research/run.mjs and research/summarise.mjs. The visual grammar follows Bycroft's tensor visualisation [2].

Credit for the ideas the paper is best known for is given in its acknowledgment: the use of timestamps to order operations, and the concept of anomalous behaviour, are due to Paul Johnson and Robert Thomas.

Go deeper: Seeds and the limits of determinism · Event time versus processing time · Eventual consistency · CAP theorem

References

Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM 21(7), 558–565 The subject of this page. Read in full from the ACM printing (pp. 558–565, figures included); every quote is checked against that text.
Bycroft, B. (2023). LLM Visualization. bbycroft.net The visual grammar of values as blocks of cells that this page follows.
Schwartz, J. T. (1962). Relativity in Illustrations. New York University Press Reference [1] of the 1978 paper, for the space-time view of ordering. Not read.
Taylor, E. F. and Wheeler, J. A. (1966). Space-Time Physics. W. H. Freeman, San Francisco Reference [2] of the 1978 paper, first chapter. Not read.
Lamport, L. (1978). The implementation of reliable distributed multiprocess systems. Computer Networks 2, 95–114 (listed in the 1978 paper as "to appear") Cited by the paper for a method that survives the failure of processes. Not read in this run.
Ellingson, C. and Kulpinski, R. J. (1973). Dissemination of system-time. IEEE Transactions on Communications COM-23(5), 605–624 Reference [4] of the 1978 paper, an introduction to physical clock synchronisation. Not read.
Fidge, C. J. (1988). Timestamps in message-passing systems that preserve the partial ordering. Proceedings of the 11th Australian Computer Science Conference, 56–66 One of the two independent introductions of vector clocks. Not read in this run: the page implements the vector rule from its standard statement and checks it against the event graph.
Mattern, F. (1989). Virtual time and global states of distributed systems. Parallel and Distributed Algorithms (eds. Cosnard, Quinton, Raynal, Robert), North-Holland, 215–226 The other independent introduction of vector clocks. Not read in this run (see Fidge).
Charron-Bost, B. (1991). Concerning the size of logical clocks in distributed systems. Information Processing Letters 39(1), 11–16 Cited in the literature for the result that a vector clock cannot have fewer entries than processes. Not read in this run; experiment E2 illustrates the claim and does not check it.

Fact ledger

Every number from the literature on this page, with the sentence it comes from. Hover any underlined number in the text to see its entry.

Value	What	Source
"happened before" is only a partial ordering	no first event	[1] Introduction In a distributed system, it is sometimes impossible to say that one of two events occurred first.
a set of events with an a priori total ordering	what a process is	[1] §The Partial Ordering In other words, a single process is defined to be a set of events with an a priori total ordering.
message delay not negligible against the time between events	what makes a system distributed	[1] Abstract A system is distributed if the message transmission delay is not negligible compared to the time between events in a single process.
	several messages in one event	[1] §The Partial Ordering, footnote 2 We allow the sending of several messages to be a single event, but for convenience we will assume that the receipt of a single message does not coincide with the sending or receipt of any other message.
	messages may arrive out of order	[1] §The Partial Ordering, footnote 2 Observe that messages may be received out of order.
the smallest relation satisfying three conditions	the happened-before relation	[1] §The Partial Ordering The relation "→" on the set of events of a system is the smallest relation satisfying the following three conditions:
same process, earlier event	condition 1	[1] §The Partial Ordering If a and b are events in the same process, and a comes before b, then a → b.
send then receive	condition 2	[1] §The Partial Ordering If a is the sending of a message by one process and b is the receipt of the same message by another process, then a → b.
transitivity	condition 3	[1] §The Partial Ordering If a → b and b → c then a → c.
"possible for a to causally affect b"	reading the arrow	[1] §The Partial Ordering a → b means that it is possible for event a to causally affect event b.
	an irreflexive partial order	[1] §The Partial Ordering This implies that → is an irreflexive partial ordering on the set of all events in the system.
	only messages actually sent	[1] §The Partial Ordering In relativity, the ordering of events is defined in terms of messages that could be sent. However, we have taken the more pragmatic approach of only considering messages that actually are sent.
neither happened before the other	concurrent events	[1] §The Partial Ordering Two distinct events a and b are said to be concurrent if a ↛ b and b ↛ a.
	the moral	[1] §Conclusion In a distributed system, it is important to realize that the order in which events occur is only a partial ordering.
	a logical clock is a counter	[1] §Logical Clocks They may be implemented by counters with no actual timing mechanism.
if a → b then C(a) < C(b)	the Clock Condition	[1] §Logical Clocks Clock Condition. For any events a, b: if a → b then C(a) < C(b).
	condition C1	[1] §Logical Clocks If a and b are events in process Pi, and a comes before b, then Ci(a) < Ci(b).
	condition C2	[1] §Logical Clocks If a is the sending of a message by process Pi and b is the receipt of that message by process Pj, then Ci(a) < Cj(b).
ticks 5, 6 and 7	ticks between consecutive events	[1] §Logical Clocks For example, if a and b are consecutive events in process Pi with Ci(a) = 4 and Ci(b) = 7, then clock ticks 5, 6, and 7 occur between the two events.
	implementation rule IR1	[1] §Logical Clocks Each process Pi increments Ci between any two successive events.
	message timestamps	[1] §Logical Clocks we require that each message m contain a timestamp Tm which equals the time at which the message was sent.
	implementation rule IR2	[1] §Logical Clocks (a) If event a is the sending of a message m by process Pi, then the message m contains a timestamp Tm = Ci(a). (b) Upon receiving a message m, process Pj sets Cj greater than or equal to its present value and greater than Tm.
	IR1 and IR2 suffice	[1] §Logical Clocks Hence, the simple implementation rules IR1 and IR2 imply that the Clock Condition is satisfied, so they guarantee a correct system of logical clocks.
	the receive after the set	[1] §Logical Clocks This is just a notational nuisance, and is irrelevant in any actual implementation.
	the converse cannot hold	[1] §Logical Clocks Note that we cannot expect the converse condition to hold as well, since that would imply that any two concurrent events must occur at the same time.
any arbitrary total ordering of the processes	breaking ties	[1] §Ordering the Events Totally To break ties, we use any arbitrary total ordering of the processes.
	the total order completes the partial one	[1] §Ordering the Events Totally In other words, the relation is a way of completing the "happened before" partial ordering to a total ordering.
	the total order is not unique	[1] §Ordering the Events Totally Different choices of clocks which satisfy the Clock Condition yield different relations.
	what is unique	[1] §Ordering the Events Totally It is only the partial ordering which is uniquely determined by the system of events.
	condition I	[1] §Ordering the Events Totally A process which has been granted the resource must release it before it can be granted to another process.
	condition II	[1] §Ordering the Events Totally Different requests for the resource must be granted in the order in which they are made.
	condition III	[1] §Ordering the Events Totally If every process which is granted the resource eventually releases it, then every request is eventually granted.
	a central scheduler fails	[1] §Ordering the Events Totally Using a central scheduling process which grants requests in the order they are received will not work, unless additional assumptions are made.
	private request queues	[1] §Ordering the Events Totally Each process maintains its own request queue which is never seen by any other process.
	every message arrives	[1] §Ordering the Events Totally Moreover, we assume that every message is eventually received.
	direct channels	[1] §Ordering the Events Totally We also assume that a process can send messages directly to every other process.
	rule 1	[1] §Ordering the Events Totally to every other process, and puts that message on its request queue
	rule 2	[1] §Ordering the Events Totally it places it on its request queue and sends a (timestamped) acknowledgment message to
	rule 3	[1] §Ordering the Events Totally and sends a (timestamped) Pi releases resource message to every other process.
	rule 5	[1] §Ordering the Events Totally is granted the resource when the following two conditions are satisfied
	rule 5 (ii)	[1] §Ordering the Events Totally has received a message from every other process timestamped later than
	the test is local	[1] §Ordering the Events Totally Note that conditions (i) and (ii) of rule 5 are tested locally by
	the State Machine	[1] §Ordering the Events Totally The synchronization is specified in terms of a State Machine, consisting of a set C of possible commands, a set S of possible states, and a function e: C × S → S.
	every process runs the machine	[1] §Ordering the Events Totally Each process independently simulates the execution of the State Machine, using the commands issued by all the processes.
	no central process	[1] §Ordering the Events Totally This is a distributed algorithm. Each process independently follows these rules, and there is no central synchronizing process or central storage.
	the cost: one failure halts everything	[1] §Ordering the Events Totally so that the failure of a single process will make it impossible for any other process to execute State Machine commands, thereby halting the system.
	failure needs physical time	[1] §Ordering the Events Totally Without physical time, there is no way to distinguish a failed process from one which is just pausing between events.
	a promised sequel	[1] §Conclusion A future paper will show how this approach can be extended to solve any synchronization problem.
	the phone call	[1] §Anomalous Behavior It is quite possible for request B to receive a lower timestamp and be ordered before request A.
	why	[1] §Anomalous Behavior This can happen because the system has no way of knowing that A actually preceded B, since that precedence information is based on messages external to the system.
	the first remedy	[1] §Anomalous Behavior the person issuing request A could receive the timestamp TA of that request from the system.
	the Strong Clock Condition is not met	[1] §Anomalous Behavior It is not in general satisfied by our logical clocks.
	physical clocks can satisfy it	[1] §Anomalous Behavior One of the mysteries of the universe is that it is possible to construct a system of physical clocks which, running quite independently of one another, will satisfy the Strong Clock Condition.
κ ≤ 10⁻⁶	drift of crystal clocks	[1] §Physical Clocks For typical crystal controlled clocks, κ ≤ 10-6.
	clocks must be synchronised	[1] §Physical Clocks It is not enough for the clocks individually to run at approximately the correct rate. They must be synchronized
	a known minimum delay	[1] §Physical Clocks we assume that the receiving process knows some minimum delay
	clocks only move forward	[1] §Physical Clocks We assume that when a clock is reset, it is always set forward and never back.
	IR1' and IR2' specialise IR1 and IR2	[1] §Physical Clocks These rules are then specializations of rules IR1 and IR2, so our system of clocks satisfies the Clock Condition.
	the diameter of the graph	[1] §Physical Clocks The diameter of the directed graph is the smallest number d such that for any pair of distinct processes Pj, Pk, there is a path from Pj to Pk having at most d arcs.
ε ≈ d(2κτ + ξ)	the theorem	[1] §Physical Clocks Then PC2 is satisfied with ε ≈ d(2κτ + ξ) for all t ≳ t0 + τd, where the approximations assume μ + ξ ≪ τ.
	the theorem's hypotheses	[1] §Physical Clocks Assume a strongly connected graph of processes with diameter d which always obeys rules IR1' and IR2'.
	the proof	[1] §Physical Clocks The proof of this theorem is surprisingly difficult, and is given in the Appendix.
	what is new about the theorem	[1] §Physical Clocks However, the requirement that clocks are never set backwards seems to distinguish our situation from ones previously studied
	claimed as new	[1] §Physical Clocks and we believe this theorem to be a new result.
	the minimum transmission time	[1] §Physical Clocks is less than the shortest transmission time for interprocess messages.
ε/(1 − κ) ≤ μ	the condition that removes the anomaly	[1] §Physical Clocks This inequality together with PC1 and PC2 implies that anomalous behavior is impossible.
Paul Johnson and Robert Thomas	credit for timestamps and the anomaly	[1] Acknowledgment The use of timestamps to order operations, and the concept of anomalous behavior are due to Paul Johnson and Robert Thomas.

How this was made

Everything on the stage is computed in the page by engine.js from the paper's rules IR1 and IR2, the five mutual exclusion rules, IR1' and IR2', and the vector clock rule. Happened-before is computed from the event graph alone, and test.mjs (8,000+ checks) compares it against a separate Floyd-Warshall closure, against hand-computed clock values and the paper's own statements about its Figure 1, the three mutual exclusion conditions on 360 simulated runs, and the physical-clock theorem on 288 runs. The paper's quotes come from the ACM printing, checked against its text and page images. The research desk is reproducible from research/.

Built with the dissection skill. The visual grammar of values as blocks of cells owes much to Brendan Bycroft's LLM Visualization. Source, tests and experiments: anatomy/architecture/2026-10-16-lamport-clocks/ in the site's repository.

Cite this page

@misc{sigmoid-lamport-clocks,
  title  = {Anatomy of Lamport Clocks},
  author = {Praveen T N},
  year   = {2026},
  note   = {Sigmoid Anatomy, interactive dissection},
  url    = {https://praveentn.live/anatomy/lamport-clocks}
}