
Dthreads: Efficient Deterministic Multithreading (2011) [pdf] - gbrown_
http://people.cs.ksu.edu/~danielwang/Investigation/System_Security/dthreads-sosp11.pdf
======
kjeetgill
> DTHREADS achieves cross-thread memory isolation by replacing threads with
> processes. In a multithreaded program running with pthreads, threads share
> all memory except for the stack. Changes to memory immediately become
> visible to all other threads. Threads share the same file descriptors,
> sockets, device handles, and windows. By contrast, because DTHREADS runs
> threads in separate processes, it must manage these shared resources
> explicitly.

They seem to be using a processes' copy-on-write memory to keep the dthreads
isolated until commit points. At commit points they deterministically merge
the pages back.

Algorithmic errors are still possible due to data races, but they present
themselves more like logic errors because they're deterministic. They'll fail
the same everytime.

Interesting.

------
e_carra
If Dthreads match the performance of pthreads, how is it possible that 7 years
from the publication they aren't widely used?

~~~
dboreham
Because they don't solve any actual problem? Races typically occur due to the
asynchronous nature of _external_ inputs (packets arrive...whenever, for
example). This project doesn't solve that problem because it only enforces
determinism _within_ the program. I'm sure you _can_ design a program such
that it suffers from entirely internal, self-generated races, but that would
be what percentage of all race bugs? 1% ?

~~~
sidkshatriya
Races occur due to internal program behavior that is different with exactly
the same external inputs.

In your packets example, if we were to feed the external inputs through a
record/replay mechanism we could debug the multi-threaded program reliably and
deterministically.

