Order known dependencies with logical counters

Model each participant as a sequence of recorded events. Earlier events on one participant precede its later events; sending a particular message precedes receiving that same message; and these relationships compose transitively. The resulting happened-before relation is a strict partial order. Events with neither direction related are concurrent in this model. That term describes missing causal order, not necessarily simultaneous physical execution. Two independent machines can perform events hours apart and still have no modeled message path connecting them. The answer also depends on where instrumentation defines the send, receive, and local events.

A participant is an ordered execution context, not automatically every thread sharing one process identifier. If a program has several concurrent threads, the local-order edges must reflect the actual synchronization model rather than an invented sequence from merged logs. An external dependency omitted from the model can also hide a real influence. State which communication channels are represented. A user copying a result between applications can create a meaningful real-world dependency that a narrow message-only trace misses. Logical time correctly represents the specified event model; it cannot manufacture knowledge of events that were never propagated or recorded.

Maintain a nonnegative logical counter at each participant. For this lesson's convention, increment before every local or send event, and attach that event's counter to the message. For a receive event carrying remote value m, replace the local counter by one more than the maximum of its previous value and m. The exact bookkeeping convention may vary, but both local sequence and send-to-receive edges must increase strictly. Consistently applying one convention makes examples auditable; mixing an increment-before convention with an increment-after diagram can produce misleading off-by-one claims.

The clock condition says that happened-before implies a smaller timestamp. Its converse does not hold. An independent participant might have executed more local events and therefore have a larger counter without learning anything about the other participant. A gap of one hundred logical units is not a hundred milliseconds, messages, or missing log entries in the global execution. It can partly reflect jumping forward after receiving a large value. Keep counter state durable or introduce a well-defined incarnation when required across restart, and prevent overflow from silently turning a later event into a smaller ordinary integer.

Two concurrent events can receive the same logical value. Adding a stable participant identifier supplies a deterministic lexicographic tie-break, producing a total order that extends happened-before. This can be useful for a protocol's arbitration rule, but it does not reveal the true physical order of concurrent events. Different legitimate identifiers or counter histories can produce different extensions. Nor does attaching timestamps alone implement reliable total-order delivery: a receiver still needs a protocol for learning when no lower-ordered event remains in flight. Representation, delivery, and application conflict resolution are separate design choices.

The modular lab demonstrates a representation hazard rather than a distributed clock. Reset, set both modulus m=8 and additive step a=1, predict what follows residue seven, then use Play or Step. Playback selects successive additions and eventually wraps to zero. Compare a fresh run only after another Reset and re-setting both controls. Ordinary numerical comparison would now place the later residue before an earlier one. Real Lamport implementations need sufficient counter space or an explicit rollover and incarnation scheme; the lab provides no messages, receive updates, or correctness protocol for handling that rollover.