A program with racing threads, restored from a saved starting point

What I ran

A .NET program with four threads racing on shared state was restored from snapshots into 96 worlds: 2 snapshot points, 2 seeds, 4 host conditions and 6 worlds for each combination.

What it shows

MIGHT. In 21 of 21 runs of a .NET program with racing threads, restored from one snapshot point on one seed, in every host condition of the gate's cycle, the restored world held the same result, console and scheduler trace as every other counted world of its cell.

The 4 cells, each a snapshot point and a seed, had 23, 21, 24 and 22 counted worlds. In every cell, the counted worlds all held the same result, the same console and the same scheduler trace. Of the 90 counted runs, 0 differed from the others that started the same way.

The same program on an ordinary computer gave 50 different final counts in 50 runs. With the kernel's own timer in a world, 8 boots gave 8 distinct counters.

What it does not show

A later run of both gates, made when the repository had uncommitted changes, is the Akka node-up result. Its singleton loaded run wrote byte-identical node logs in 33 of 36 worlds, because three worlds were set aside as their job shared a core with another process.

That a program that reads a clock in a loop, uses the random pool after the snapshot, or runs more than one process or vCPU matches: the gate does not claim it.

That the native program still matches on the newest build. Its latest run from a committed tree is a committed-tree ledger REFUSED: the gate gave no verdict, so the native figures here are from the earlier runs. A later row of this gate, an uncommitted-tree ledger PASS, is not read here.

Conditions

The jitter was up to 50,000 branches.