Priority records and their stabilization #
A priority construction keeps, at each stage, a finite list of records indexed by priority, with
smaller index meaning higher priority. When requirement e receives attention it installs a new
record at position e and resets every record of lower priority: the list is truncated after
position e. This is the initialization of lower-priority requirements. It is bookkeeping about
records only; whether a reset is accompanied by an injury, an entry into a protected oracle
interval, is a separate question that this file does not address.
The update is guarded: attention at a priority beyond the end of the list leaves the records unchanged. Without the guard, truncating and appending would place the new record at the end of the list, a position of higher priority than the attending requirement.
Main definitions #
TauCeti.Priority.Update: a priority together with the record to install there.TauCeti.Priority.Update.apply: the guarded update of a list of records.TauCeti.Priority.run: the records afternstages of a schedule of updates.TauCeti.Priority.attentionStages: for a priority scheduleℕ → Option ℕ, the run indicess + 1after which an update of prioritye, scheduled at stages, has been applied.
Main results #
TauCeti.Priority.Update.getElem?_apply_of_lt: locality. An update at priorityeleaves every record of strictly higher priority unchanged.TauCeti.Priority.Update.getElem?_apply_of_gt: after an update, no record of strictly lower priority remains.TauCeti.Priority.disjoint_attentionStages: distinct requirements have disjoint attention stages.TauCeti.Priority.finite_attentionStages_of_local: if each requirement receives attention finitely often whenever every higher-priority requirement does, then every requirement receives attention finitely often.TauCeti.Priority.exists_forall_getElem?_run_eq_of_finite: if requirements0, …, eeach receive attention finitely often, the record at positioneeventually stops changing.TauCeti.Priority.exists_forall_getElem?_run_eq_of_local: under the conditional local finiteness hypothesis, every record eventually stops changing.
The stabilization theorem assumes only the conditional local finiteness of attention: no scheduling discipline, no bound on how often a requirement receives attention, and no effective stabilization stage. Stabilization of a record is not satisfaction of its requirement.
References #
- R. I. Soare, Recursively Enumerable Sets and Degrees, Springer, 1987, Chapter VII.
- Ported from
cameronfreer/computable-model-theoryat commita1fe76155a98f03933f7de0811e03b2473dd2e21:ComputableModelTheory/Computability/FiniteInjury.leanand its auditFiniteInjuryAudit.lean. - Divergences from that source: records are a plain
Listrather than a wrapper structure; truncation of lower-priority records is called a reset (initialization), not an injury; attention is counted by the setsattentionStagesof a priority scheduleℕ → Option ℕ, and local finiteness is stated as finiteness of these sets; the separate goodness predicate is not included.
Runs #
Attention and stabilization #
A priority schedule action : ℕ → Option ℕ records which requirement, if any, receives attention
at each stage. The update scheduled at stage s has been applied in the records run sched init (s + 1), so attention is counted by these run indices s + 1. A schedule of updates gives the
priority schedule fun s => (sched s).map Update.prio.
Distinct requirements have disjoint attention stages.
Priority induction. If each requirement receives attention finitely often whenever every higher-priority requirement does, then every requirement receives attention finitely often.
If requirements 0, …, e each receive attention finitely often, then from some stage on every
requirement receiving attention has priority beyond e.
From a stage after which only updates of priority beyond e are scheduled, the record at
position e never changes.
Stabilization of one record. If requirements 0, …, e each receive attention finitely
often, then the record at position e eventually stops changing.
Stabilization. If each requirement receives attention finitely often whenever every higher-priority requirement does, then every record eventually stops changing.