# Completion, reset and execution epochs Canonical: https://semiaifoundry.com/learn/atlas/device-completion-reset-epochs/ Revision: 2026-10-07 Rights: https://semiaifoundry.com/ai-atlas/licenses.html Executable software · Atlas v1.3.0 # Completion, reset and execution epochs Separate physical work, accepted completion and useful output while a device is stopped and reinitialized. [Explore in Atlas](https://semiaifoundry.com/ai-atlas/#device-completion-reset-epochs)One process and device job; logical states and byte addresses, no timing or physical geometry Learning objectiveReconcile partial output, discarded arithmetic and one accepted result across a device reset, and reject an old or duplicate completion. ## The mechanism An asynchronous device job can have written some output without establishing an accepted completion. Reset makes that distinction consequential: the host must not assume that every in-flight request finished, or that none of its side effects occurred. The teaching recovery path first establishes quiescence, retires the old queue and mappings, and cancels the uncommitted attempt. It then optionally runs the same pure matrix job under a new epoch with intact host inputs. The stable job identity connects both attempts, while the epoch prevents an older host-side notification from authorizing the new result. Every executed multiply-accumulate remains counted, including work whose partial output is discarded. The accepted consumer result appears once after all current-attempt writes, matching completion identity and output visibility. This finite replay is safe only under the stated pure-operation contract; repeating external side effects would require a stronger application recovery design. 1. A descriptor carries the stable job ID and the current execution epoch. 2. Every output cell is written before the normal completion record is posted. 3. Reset-needed stops the host from treating the old attempt as successful; the device is then assumed quiescent only at reset acknowledgement. 4. The old attempt’s arithmetic becomes discarded work, and its queue/mappings are retired before reuse. 5. An optional retry reestablishes readiness and performs the same operation under a new epoch. 6. A previously queued host notification for the old epoch is rejected; only one matching current completion can authorize publication. ## Science and assumptions ### Account every executed MAC $$ N_{\mathrm{executed}}=N_{\mathrm{active}}+N_{\mathrm{discarded}}+N_{\mathrm{committed}} $$ Executed MACs equal active, discarded and committed MACs at every event. Symbols and units Nexecuted All performed multiply-accumulates MAC count Nactive Work in the current uncommitted attempt MAC count Ndiscarded Work belonging to canceled attempts MAC count Ncommitted Work in the once-accepted attempt MAC count Reset moves the uncommitted attempt’s active count to discarded. Publication moves the accepted attempt’s active count to committed. Committed arithmetic is still separately checked for semantic correctness. Assumptions Exact finite ledger of this one pure 2×2 job, at most one reset and one retry. Reads and writes are accounted separately in bytes. ### Completion must belong to the live attempt $$ G_{\mathrm{completion}}=(j_c=j_a)\land(e_c=e_a)\land Q\land W\land\neg A_c $$ Completion acceptance requires matching job and epoch, a live queue, all output cells written and no prior acceptance. Symbols and units jc,ja Completion and active job identities identifier ec,ea Completion and active epochs count Q Queue and published descriptor are live Boolean W All four output cells have been written Boolean Ac A completion was already accepted Boolean The implementation additionally requires a published live descriptor. A repeated notification cannot cause a second accepted result. Assumptions A bounded local protocol. Epochs are identifiers here, not cryptographic tokens or a distributed exactly-once guarantee. ## Engineering example Reset the default job after its second output cell. The old memory contains \[19,22,−777,−777\], but no C is published. A retry performs eight more MACs, producing 12 executed = 4 discarded + 8 committed, with 64 input read bytes and 24 output write bytes across both attempts. It publishes \[\[19,22\],\[43,50\]\] once. Stop instead publishes nothing. Reset after all four writes still cancels eight uncommitted MACs when the completion boundary has not been crossed. ## Distinctions and tradeoffs Physical writes and notifications do not independently establish that an entire intended job is safe to publish. Keeping inputs and tracking generations enables this pure-job retry. The model does not restore corrupted input memory, repair firmware or make side-effecting requests safely replayable. Long-running accelerator services need to separate retried execution from completed useful requests. Recovery correctness is part of delivered compute capacity, not merely an availability percentage. ## Specifications and interfaces Job identity matrix-job-1 Retained across attempts; completion also needs the active epoch. Default reset position After two output cells Four MACs have executed and eight output bytes have been written. Retry assumption Intact inputs and acknowledged quiescence No fault rate, repair latency or external side-effect recovery is inferred. ### Interfaces Declared runtime inputs Input Stable matrix job, buffer identities and the stated device/visibility contract Inspectable accepted or rejected result Output Event trace, actual buffer values and bounded completion/work ledger ## Check your understanding ### A reset cancels four MACs, then a full retry executes eight. How much arithmetic was executed and committed? 1. Eight executed, eight committed 2. Twelve executed, twelve committed 3. Twelve executed, eight committed Answer and reasoning Twelve executed, eight committed The canceled four MACs remain physical work but do not belong to the accepted attempt. ## Evidence and scope Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed. The commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator. ## Sources - [OASIS — Virtual I/O Device (VIRTIO) Version 1.3](https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html) [Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/device-completion-reset-epochs-25590d0d23232447.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html) ## Continue exploring ### Foundations - [DMA visibility, ordering and buffer lifetime](https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/) - [Firmware handoff and device readiness](https://semiaifoundry.com/learn/atlas/firmware-device-contract/) ### Related lessons - [When completed work survives a restart](https://semiaifoundry.com/learn/atlas/retained-work-restart-boundary/) - [Checkpointing, failure and retained useful work](https://semiaifoundry.com/learn/atlas/checkpoint-retained-work/) - [Commissioning a usable AI cluster](https://semiaifoundry.com/learn/atlas/cluster-commissioning-gates/)