High-performance determinism with total store order consistency

Abstract

We present CONSEQUENCE, a deterministic multi-threading library. CONSEQUENCE achieves deterministic execution via store buffering and strict ordering of synchronization operations. To ensure high performance under a wide variety of conditions, the ordering of synch operations is based on a deterministic clock [25], and store buffering is implemented using version-controlled memory [23].Recent work on deterministic concurrency [14,19] has proposed relaxing the consistency model beyond total store order (TSO). Through novel optimizations, CONSEQUENCE achieves the same or better performance on the Phoenix, PARSEC and SPLASH-2 benchmark suites, while retaining TSO memory consistency. Across 19 benchmark programs, CONSEQUENCE incurs a worst-case slowdown of 3.9× vs. pthreads, with 14 out of 19 programs at or below 2.5×. We believe this performance improvement takes parallel programming one step closer to "determinism by default."

Lazy Determinism for Faster Deterministic Multithreading

“…Communication may be restricted through thread isolation techniques (in the case of strong determinism), and the order of operations is regulated by a deterministic logical clock (DLC). LD adds lazy determinism to C [30], an existing deterministic execution environment. We briey review the operation of C below.…”

“…These benets come at a performance cost, however, particularly for synchronization-intensive programs. In all existing DMT systems, both those that determinize the outcome of data races (strong determinism schemes) [4,15,19,26,27,30,32] and weak determinism schemes that ignore races [33], deterministic ordering is eagerly enforced. As a result, synchronization operations follow a deterministic total order regardless of variable.…”

Monadic composition for deterministic, parallel batch processing

“…Since threads in libdet run sequentially, some programs will deadlock if they use spin-waiting. We plan to use a more general deterministic runtime system [Kai Lu et al 2014;Liu et al 2011;Merrifield et al 2015;Merrifield and Eriksson 2013] to enable true concurrency in future work. 6 CASE STUDIES 6.1 Case Study 1: Parallel Software Builds with detmake To exercise DetFlow's capabilities, we developed a clone of the GNU make build tool using DetFlow, which we have named detmake.…”

“…There are also many runtime systems that focus on making programs deterministic in a languageagnostic way. Some focus on programs without data races [Olszewski et al 2009], while others focus on making even racy programs deterministic via hardware support [Devietti et al 2009[Devietti et al , 2011Hower et al 2011] or purely in software [Kai Lu et al 2014;Liu et al 2011;Merrifield et al 2015;Merrifield and Eriksson 2013]. 9 DISCUSSION AND FUTURE WORK 9.1 Implementation in Other Languages Implementing a framework like DetFlow does not require a purely functional language like Haskell as the coordinator language.…”

“…For example, efforts like the Nix package manager [Nix 2015] and the Debian Reproducible Builds project [Debian Wiki 2016] share a goal of reproducible software builds, but have made progress only through extensive human effort to manually identify and remove sources of nondeterminism in the build. Existing deterministic languages [Bocchino et al 2009], runtime systems [Merrifield et al 2015;Olszewski et al 2009], and hardware architectures [Devietti et al 2009;Hower et al 2011] are of little help with these real-world challenges as they operate within the process abstraction, focusing only on nondeterminism arising from shared-memory interactions. Deterministic operating systems [Aviram et al 2010;Bergan et al 2010;Hunt et al 2013] can make interprocess communication deterministic, but require a custom OS that is often impractical to deploy.…”