Deterministic multithreading is hard (2024) • Hacker News Board

Re: Deterministic multithreading is hard (2024)

#11

Post by OskarS » Mon, Oct 20, 2025, 3:22 PM UTC

btown wrote: post #4

nickpsecurity wrote: post #3

My favorite paper on it doing a clever workaround: https://github.com/emeryberger/dthreads

Paper link (2011): https://people.cs.umass.edu/~emery/pubs/dthreads-sosp11.pdf > DTHREADS works by exploding multithreaded applications into multiple processes, with private, copy-on-write mappings to shared memory... Experimental results show that DTHREADS substantially outperforms a state-of-the-art deterministic runtime system, and for a majority of the benchmarks evaluated here, matches and occasionally exceeds t…

Never heard of this, I’m really interested in digging into this paper. Thank you both for the tip!

Re: Deterministic multithreading is hard (2024)

#12

Post by seg_lol » Mon, Oct 20, 2025, 9:10 PM UTC

nickpsecurity wrote: post #3

My favorite paper on it doing a clever workaround: https://github.com/emeryberger/dthreads

Emery Berger is one of my favorite researchers, his work has a fun bright quality that delights!

Re: Deterministic multithreading is hard (2024)

#13

Post by nickpsecurity » Tue, Oct 21, 2025, 4:07 AM UTC

seg_lol wrote: post #12

nickpsecurity wrote: post #3

My favorite paper on it doing a clever workaround: https://github.com/emeryberger/dthreads

Emery Berger is one of my favorite researchers, his work has a fun bright quality that delights!

I agree. I skimmed so many of his team's papers one night. I could've submitted a bunch of them.

Re: Deterministic multithreading is hard (2024)

#14

Post by nickpsecurity » Tue, Oct 21, 2025, 4:11 AM UTC

vlovich123 wrote: post #6

nickpsecurity wrote: post #3

My favorite paper on it doing a clever workaround: https://github.com/emeryberger/dthreads

What’s interesting to me about Prof Berger’s work is that while many of his ideas are seemingly powerful and should be very impactful, it’s underutilized in practice. I think that’s because he’s failed to figure out how to really make it easy to use and productized. For example, Coz should be the definitive tool and mechanism people use to do performance analysis. However because it’s so hard to use and fails in vari…

Good points. Thanks for the reference to Coz.

One of the researchers behind either rump kernels or unikernels talked to us here about making it usable. He said he was discouraged by his advisors from doing that. He could write more papers instead.

The reason they think that was is it's quantity over quality in much of academia, esp citation scores and funding for new research. Some groups seem to have their researchers use some of their time to build useful software. Most isn't production quality or maintained because they're basically paid not to do that. It's why many don't join academic research and others supported funding cuts or reform.