Detecting and tolerating asymmetric races

Abstract

This paper introduces ToleRace, a runtime system that allows programs to detect and even tolerate asymmetric data races. Asymmetric races are race conditions where one thread correctly acquires and releases a lock for a shared variable while another thread improperly accesses the same variable. ToleRace provides approximate isolation in the critical sections of lock-based parallel programs by creating a local copy of each shared variable when entering a critical section, operating on the local copies, and propagating the appropriate copies upon leaving the critical section. We start by characterizing all possible interleavings that can cause races and precisely describe the effect of ToleRace in each case. Then, we study the theoretical aspects of an oracle that knows exactly what type of interleaving has occurred. Finally, we present two software implementations of ToleRace and evaluate them on multithreaded applications from the SPLASH2 and PARSEC suites. Our implementation on top of a dynamic instrumentation tool, which works directly on executables and requires no source code modifications, incurs an overhead of a factor of two on average. Manually adding ToleRace to the source code of these applications results in an average overhead of 6.4 percent.

Pacman: Tolerating asymmetric data races with unintrusive hardware

“…This is a data race where at least one of the racing threads is inside a synchronization-protected critical section [22,23]. In addition, we are interested in efficiently tolerating them in production runs.…”

“…It occurs when at least one of the racing threads is inside a synchronization-protected critical section [23]. In this case, while a thread (call it safe) is accessing shared variables inside a critical section, a second thread (call it unsafe) races in, corrupting the state or reading inconsistent state.…”

“…For example, Figure 1 shows a case where thread T1 is the safe thread. These races are common in bug reports, and can often appear in welltested codes that interact with third-party or legacy routines [23]. They are likely harmful because the data being corrupted is critical data already protected by synchronization.…”

“…They are likely harmful because the data being corrupted is critical data already protected by synchronization. Interestingly, these races have received little attention [22,23].…”

“…There are only two proposals that specifically target asymmetric data races: ToleRace [23] and ISOLATOR [22]. They both use race tolerance and are software-based.…”