5 ms·

The reason for using a single underlying thread/process is to prevent the OS scheduler from interfering with deterministic execution. You can't control how and

The reason for using a single underlying thread/process is to prevent the OS scheduler from interfering with deterministic execution. You can't control how and when the OS scheduler kicks in, nor can you perfectly reproduce the clock drift/jitter between multiple cores. If the program under test spawns threads, then you'll have to emulate the execution of those threads by writing your own scheduler whose time slicing and scheduling policies are done deterministically.

Veserv 2y ago
You can control scheduling; that is how many record-replay based time-traveling debuggers do it. Also, scheduling is independent of deterministic execution unless you are doing inherently non-deterministic things like multithreaded shared memory accesses which you can not simulate faithfully anyways. The only thing that matters in a deterministic execution model is runs of deterministic execution interrupted with non-deterministic events injected at precise points in the execution trace. When serializing onto a single thread you already need to define some sort of correspondence between "simulated scheduler state" to number of instructions to execute as you are already giving up on the actual scheduler (unless you do not care about correspondence to the actual schedule configuration). You just do that, but you get to execute with all of your cores until you reach the injection point (which is how replay systems can work already). Now you can execute in parallel (multiprocessing only though, no multithreading) and use blocking I/O.
joncrocks 2y ago
This depends on what you're testing. If you're collapsing threads/processes into a single thread you're making decisions about the order of execution anyway so you're not going to catch errors introduced around unexpected preemption or inter-core process/thread timing issues. If you're not looking for that then you can build your software/system to have known sync-points where you can allow a given process to stop/wait and allow other processing to occur. This can then be in-process/out of process/remote. As you say, this ends up being a scheduler with which you have to employ knowledge about the execution/communication channels in order to coordinate correctly.

Veserv 2y ago

You can control scheduling; that is how many record-replay based time-traveling debuggers do it. Also, scheduling is independent of deterministic execution unless you are doing inherently non-deterministic things like multithreaded shared memory accesses which you can not simulate faithfully anyways. The only thing that matters in a deterministic execution model is runs of deterministic execution interrupted with non-deterministic events injected at precise points in the execution trace. When serializing onto a single thread you already need to define some sort of correspondence between "simulated scheduler state" to number of instructions to execute as you are already giving up on the actual scheduler (unless you do not care about correspondence to the actual schedule configuration). You just do that, but you get to execute with all of your cores until you reach the injection point (which is how replay systems can work already). Now you can execute in parallel (multiprocessing only though, no multithreading) and use blocking I/O.

joncrocks 2y ago

This depends on what you're testing. If you're collapsing threads/processes into a single thread you're making decisions about the order of execution anyway so you're not going to catch errors introduced around unexpected preemption or inter-core process/thread timing issues. If you're not looking for that then you can build your software/system to have known sync-points where you can allow a given process to stop/wait and allow other processing to occur. This can then be in-process/out of process/remote. As you say, this ends up being a scheduler with which you have to employ knowledge about the execution/communication channels in order to coordinate correctly.