ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 21 – Debugging, Tracing, and Determinism

EMulatR explicitly identifies potential nondeterminism sources and applies control strategies to each:

Source	Risk	Control Strategy
Device timing	Devices execute asynchronously and may signal completion at host-dependent times	Optional deterministic scheduling mode — device progress advances only when CPU cycles advance, eliminating host timing variance
Interrupt arrival	Asynchronous interrupts could arrive at unpredictable points	Sampled at fixed run-loop points only — checkInterrupts() executes at instruction boundaries, never mid-instruction
DMA completion	DMA transfers complete asynchronously on host threads	Explicit completion events delivered through the interrupt system — visible only at sampling points
SMP race windows	Cross-CPU memory accesses may interleave differently	Architectural serialization via explicit barriers, atomic operations, and MemoryBarrierCoordinator synchronization
Host thread timing	QThread scheduling on the host OS is nondeterministic	Emulator-controlled ordering — CPU run loops are synchronized via ExecutionCoordinator, device I/O threads communicate only through atomic state

Devices are the primary source of nondeterminism. The deterministic scheduling mode (when enabled) forces all device state transitions to occur in lockstep with CPU cycles, converting asynchronous behavior into synchronous behavior at the cost of reduced host performance. In non-deterministic mode, device timing reflects host system behavior, which may be acceptable for interactive use but unsuitable for regression testing.

Host-specific optimizations that compromise determinism — such as JIT compilation or host SIMD acceleration — are excluded from the design by policy.

See Also: Chapter 16 – Device Model & DMA (device timing model); Chapter 19 – Interrupt Architecture & IPI (interrupt sampling semantics).

21.2 Sources of Nondeterminism

21.2 Sources of Nondeterminism