xenia-rs/audit-runs/phase-c23-scheduler-determinism-plan/candidate-strategies.md

Candidate strategies — Phase C+23

Five candidate strategies for aligning canary↔ours contention. Each evaluated on: implementation, scope, behavior risk, coverage, compatibility with existing absorbers.

(α) Lockstep cooperative scheduler — both engines

What

Run both engines as single-host-thread cooperative schedulers, with a shared deterministic policy for "which guest thread runs next at each scheduling boundary". Canary would lose its 1-host-per-1-guest model; ours already cooperative.

Scope

• canary: ~2000-3000 LOC across kernel/xthread.cc, base/threading.cc, base/threading_posix.cc, base/threading_win.cc, cpu/processor.cc. Replace Thread::Create with a fiber/coroutine runtime. All pthread_cond_wait-style waits become explicit scheduler calls.
• ours: ~0 LOC (already in this model).

Behavior risk

HIGH. Canary is the oracle. Reworking its scheduling philosophy could break game-compat regression (other titles depend on the host-thread behavior). Re-validating Sylpheed alone would not certify this for the broader canary test corpus.

Coverage

ALL contention sources, deterministically.

Compatibility

Replaces C+18 / C+21 / D-extension absorbers (they become moot once canary is bit-deterministic). But: if the cooperative canary picks a different schedule than ours, the matched-prefix gain is zero — both still diverge, just deterministically. Needs a shared policy.

Verdict

Overscoped. Already rejected in 2026-05-18 plan as approach B.

---

(β) Deterministic preemption points — both engines

What

Define a finite set of scheduling boundaries that BOTH engines honor (e.g., kernel-call entry, xeKeWaitForSingleObject, RtlEnterCriticalSection, quantum exhaustion, page-boundary crossings). Between these points, threads run monolithically. The policy at each point is deterministic (e.g., "lowest tid among Ready wins").

Scope

• canary: ~1000 LOC. Add a xe::DeterministicScheduler layer that intercepts kernel-call entry; if multiple guest threads are competing, picks via the shared policy. Disable host preemption outside boundaries (set per-thread SCHED_FIFO or use a global scheduler_mutex released only at boundaries).
• ours: ~200 LOC. Modify Scheduler::round_schedule and decrement_quantum to honor the same boundary set.

Behavior risk

HIGH on canary. Same oracle-stability concern as (α). MEDIUM on ours; the rotation-at-boundaries is a small generalization of existing logic.

Coverage

ALL kernel-mediated contention. Does NOT cover non-kernel guest atomics (rare in Sylpheed — probed at 0 occurrences in import inventory).

Compatibility

Subsumes C+18 / C+21 / D-extension. Same shared-policy requirement as (α).

Verdict

The right structural answer in principle, but the engineering investment (1200+ LOC across two engines, including a host-side priority-inversion-safe mutex layer in canary) is multi-session heavy. Multi-month-long subaudit. Not justified for the residual divergence past 105,046 unless future titles need it.

---

(γ) Recorded scheduling trace — canary records, ours replays

What

Canary emits a high-fidelity scheduling trace (every park/wake/ context-switch + the guest-cycle each happens at). Ours consumes this trace as its scheduling oracle: at each scheduling point, ours forces its decision to match the trace.

This generalizes Phase D's contention-manifest from "1 event class on 1 primitive" to "every scheduling decision."

Scope

• canary: ~200 LOC (extend kernel_emit_contention to emit sched.park, sched.wake, sched.yield, sched.priority_change).
• ours: ~400 LOC (a generalized SchedulingTraceReplayer consulted at every park / wake / quantum decision).
• Diff tool: ~50 LOC engine-local kinds.

Behavior risk

LOW on canary (additive emit only, cvar-gated default-off). MEDIUM on ours (replay mode is a new schedule policy; default mode unchanged).

Coverage

ALL kernel-mediated contention, ALL wait timeouts, ALL priority adjustments. Strong.

Compatibility

Mostly subsumes C+18 / C+21 absorbers (they remain as safety nets). D-extension absorber may still be needed if upstream state-mutation timing differs by a few host instructions in regions canary's trace doesn't precisely cover.

Verdict

The "right next step" if structural alignment is the goal. The Phase D Stages 1-4 work is the foundation for this; γ broadens to other event classes. Risk: the trace can be enormous (millions of entries for Sylpheed), and the cost-benefit depends on how many additional events past 105,046 a broader trace would unlock.

---

(δ) Wine-level controls — single-CPU pin + RT priority

What

Run canary under Wine with taskset -c 0, chrt --rr 99, disable kernel preemption flags. Reduce canary's host-OS jitter without modifying code.

Scope

• 0 LOC engine. ~10 LOC bash wrapper.

Behavior risk

MEDIUM. Wine's internal threads (ntdll server, GPU shim) still race with the game's guest threads; pinning all of them to one core serializes but doesn't guarantee a specific interleaving order. Aggressive RT priority could hang the rig if a tight spin loop forms.

Coverage

PARTIAL — reduces jitter range, doesn't eliminate. Empirical jitter profile suggests jitter range is already small (0-3 wait.begin events per cold), so the marginal reduction is small.

Compatibility

Orthogonal — works alongside absorbers. Could be combined with γ to reduce trace size by reducing canary's natural variance.

Verdict

Cheap, worth trying as a probe, but unlikely to bit-stabilize canary because Wine itself has internal non-determinism. Recommend as a small empirical experiment, not as the structural fix.

---

(ε) Atomic-operation determinism — ours emulates canary's host

What

Change ours's atomic-op semantics so that, e.g., when ours's tid=1 performs atomic_cas(-1, 0, &cs->lock_count), the outcome matches what canary's host atomics would produce given the same instruction ordering. Requires modeling canary's host-OS scheduling decisions inside ours.

Scope

Effectively (γ) but at a finer grain. ~600 LOC.

Behavior risk

HIGH. Atomic-op semantics are a fundamental primitive; changing them risks breaking unrelated PowerPC instruction emulation.

Coverage

ALL contention. But the LOC growth is large because PowerPC has multiple atomic instructions (lwarx/stwcx., loadarrowright, etc.) each needing the replay hook.

Compatibility

Subsumes everything. Conflicts with the existing Scheduler.

Verdict

Theoretical only. Don't pursue.

---

(ζ) Stay with the band-aid

What

Accept that the matched-prefix metric is unreliable in contention regions. Continue using C+18 / C+21 / D-extension absorbers; if new divergence classes appear past 105,046, add narrow absorbers as needed.

Scope

0 LOC engine. Diff-tool absorber additions: ~50-150 LOC per new class as it appears.

Behavior risk

LOW. Band-aids are explicitly annotated; the absorber chain has 3 layers but each is narrow.

Coverage

Up to ε. The 104,607 cap is unblocked to 105,046. The NEXT cap (VdInitializeEngines, the VD-subsystem bug) is unrelated to scheduling.

Compatibility

Self-consistent. Already in production.

Verdict

Cheapest viable answer. The next divergence is not scheduling; no further scheduler-determinism work is needed UNTIL a future cap recurs from scheduler asymmetry.