Brief Announcement: Detectable Sequential Specifications for Recoverable Shared Objects

Abstract

The recent commercial release of persistent main memory by Intel has sparked intense interest in recoverable concurrent objects. Specifying and implementing such objects is technically challenging on current generation hardware precisely because the top layers of the memory hierarchy (CPU registers and cache) remain volatile, which causes application threads to lose critical execution state during a failure. Friedman, Herlihy, Marathe, and Petrank (DISC'17) recently proposed that this difficulty can be alleviated by making the recoverable objects detectable, meaning that during recovery, they can resolve the status of an operation that was interrupted by a failure. In this paper, we formalize this important concept using a detectable sequential specification (DSS), which augments an object's interface with auxiliary methods that threads use to first declare their need for detectability, and then perform detection if needed after a failure. Compared to prior work on this topic, our DSS-based approach is less reliant on assumptions regarding the system, and more flexible in the sense that it allows applications to request detectability on demand. As a proof of concept, we present a detectable recoverable lock-free queue algorithm and evaluate its performance on a multiprocessor equipped with Intel Optane persistent memory. Our queue outperforms the detectable log queue of Friedman, Herlihy, Marthe, and Petrank (PPoPP'18) by up to 1.7×.

Practical Detectability for Persistent Lock-Free Data Structures

“…We argue that durable linearizability, while being widely accepted, is generally insufficient to use persistent lock-free DSs for transaction processing. Durable linearizability does not tell about detectability, or in other words, when an operation is interrupted in the middle by a crash, whether it is finished or not [9,10,24,42]. The lack of detectability-while ensuring the DS's own consistencymay break the enclosing system's consistency in case of crashes.…”

“…Challenges. Several detectable persistent lock-free DSs have been proposed in the literature [9,10,24,42,50], but to the best of our knowledge, all of them suffer from at least one of the following limitations:…”

“…• High runtime overhead: Detectability generally incurs runtime overhead. While the overhead is modest for hand-tuned persistent DSs [24,42,50], it is significant for the general transformation in [10] for two reasons. First, an object supporting detectable CAS consumes 𝑂 (𝑃) space in PM where 𝑃 is the number of threads, prohibiting its use for space-efficient DSs such as hash tables and trees.…”

“…al. [42] and (nb)Montage [12,57] use epoch-based reclamation [22] for reclaiming PM locations, but its technical details are not sufficiently discussed in the papers. Attiya et.…”

“…We argue that reclamation for PM is extremely subtle and deserves more attention. First, we discover that the queues in [24,42] may incur use-after-free in case of crashes due to a lack of flush. Second, a straightforward application of reclamation schemes to PM may incur double-free in case of thread crashes.…”