Bound a lease using explicit clock assumptions

A lease is not simply a cached boolean saying that a lock was acquired. It grants a named holder particular rights over a resource under stated expiration and renewal rules. The grantor must not give incompatible rights to another holder while the original grant can still be valid. The holder must stop exercising those rights according to a conservative interpretation of its own timer. Record grant identity, scope, term, and the event that begins each timer. Comparing two printed absolute timestamps without a shared clock-error contract is not an adequate substitute for this state model.

Duration-based protocols can use bounded clock rates without requiring identical clock offsets. For a local elapsed clock advancing between 1−rho and 1+rho times physical rate, a measured duration can finish earlier or later in real time. A safety argument compares the holder's latest possible stopping time with the grantor's earliest possible expiration time. Define suspension behavior too: a timer that excludes a long process or machine suspension may not measure the passage of time relevant to a remote grantor. A local monotonic API protects certain ordering properties, but its name alone does not establish every lease assumption.

Consider a specific simplified protocol. The holder starts its timer when sending the grant request, before the grantor can begin its own grant timer. The grantor's local term is Ls; the holder uses a shorter local term Lc. With holder rate error bounded by rho_c and grantor rate error by rho_s, the holder must stop no later than its slow-clock worst case. The grantor can expire as early as its fast-clock worst case. Requiring the former duration not to exceed the latter gives a conservative inequality, helped by the holder's timer starting earlier.

This is an illustrative rule, not a universal implementation prescription. A different timer-start event or a protocol based on bounded absolute-time intervals requires its own derivation. A delayed grant reply can arrive after the holder's conservative term has already ended; receiving the reply does not revive that expired interval. Renewals must specify which grant they extend and must not be accepted ambiguously after authority changes. A grantor restart or failover also cannot simply forget outstanding leases and issue conflicting grants. Durable grant state, an appropriate recovery wait, or another proven mechanism is part of the safety argument.

Even if the holder checks its timer before issuing a write, the process can pause afterward or the request can remain delayed in a network. The protected resource may observe that old operation after another holder has acquired authority. A lease argument about when a client issues work does not automatically prove when the resource applies it. Depending on the resource and protocol, validation at the resource, fencing, bounded operation completion, or another explicit mechanism is needed. Similarly, a holder that resumes after a long pause must re-establish its current authority rather than act on a stale in-memory assumption.

The replica instrument shows only one availability ingredient. For each separate configuration, Reset, set both replica count n=5 and unavailable count k, predict the available count and majority, then inspect. Compare k=2 with a fresh k=3 configuration. Three available replicas form a numerical majority; two do not. This diagram contains no grants, clock drift, quorum-vote history, or expiration rules. A majority being reachable can enable a correctly designed authority service to progress, but cannot by itself prove that an old lease expired or that an in-flight operation is rejected.