"Atomic" vs "Transactional" terminology note

(originally from https://github.com/Agoric/agoric-sdk/pull/5635#discussion_r921706341 )

If there are official CS definitions for "atomic" and "transactional", please let me know. In the meantime, this note documents how I use these terms, and how we should.

By atomic, I mean "executes without interleaving of any other activity that might mutate synchronously accessible state". For us, the interleavings relevant to atomicity happen at turn boundaries. For the interleaving of synchronous code within a turn, we generally say "reentrancy" and do not describe reentrancy hazards as violations of atomicity. Thus, for us, turns are atomic. Action that completes within a turn is atomic.

By transactional I mean an all-or-nothing constraint about a set of effects. SwingSet guarantees that cranks are transactional. Everything that happens within the crank (including the processing of non-fatal errors) all happen if computation continues with the outcome of this crank. If, OTOH, a fatal error is encountered that causes vat death before the crank completes, then SwingSet guarantees a full transactional-abort of the crank. No effects that happened in the crank prior to the fatal error are ever observable by anything else.

Cranks are transactional but not atomic, because activity started within one turn of the crank may interleave with activities started by other turns within the same crank.

Our upgrade mechanism makes use of the transactional nature of the first crank of the upgraded (successor) vat. If this first crank fails, then the upgrade fails and the ancestor vat is not yet destroyed.

Our no nested await rules are all about atomicity, minimizing surprise caused by the interleaving of other code at turn boundaries.