Completion, reset and execution epochs

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.

A descriptor carries the stable job ID and the current execution epoch.
Every output cell is written before the normal completion record is posted.
Reset-needed stops the host from treating the old attempt as successful; the device is then assumed quiescent only at reset acknowledgement.
The old attempt’s arithmetic becomes discarded work, and its queue/mappings are retired before reuse.
An optional retry reestablishes readiness and performs the same operation under a new epoch.
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?

Eight executed, eight committed
Twelve executed, twelve committed
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.