3 ms·

Dthreads: Efficient Deterministic Multithreading (2011) [pdf]

36 points by gbrown_ 8y ago

e_carra 8y ago
If Dthreads match the performance of pthreads, how is it possible that 7 years from the publication they aren't widely used?
- cjcole 8y ago
  It's not a drop-in replacement: "Unsupported Benchmarks: We were unable to evaluate DTHREADS on seven of the PARSEC benchmarks: vips and raytrace would not build as 32-bit executables; bodytrack, facesim, and x264 depend on sharing of stack variables; fluidanimate uses ad-hoc synchronization, so it will not run without modifications."
- dboreham 8y ago
  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 8y ago
    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.
- mzs 8y ago
  Cause it's linux only? >>> 4.1.1 Thread Creation DTHREADS replaces the pthread_create() function with the clone system call provided by Linux. ...
kjeetgill 8y ago
> 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.

36 points by gbrown_ 8y ago

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

cjcole 8y ago
It's not a drop-in replacement: "Unsupported Benchmarks: We were unable to evaluate DTHREADS on seven of the PARSEC benchmarks: vips and raytrace would not build as 32-bit executables; bodytrack, facesim, and x264 depend on sharing of stack variables; fluidanimate uses ad-hoc synchronization, so it will not run without modifications."
dboreham 8y ago
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 8y ago
  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.
mzs 8y ago
Cause it's linux only? >>> 4.1.1 Thread Creation DTHREADS replaces the pthread_create() function with the clone system call provided by Linux. ...

kjeetgill 8y ago

> 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.