Safe privatization in transactional memory

Abstract

Transactional memory (TM) facilitates the development of concurrent applications by letting the programmer designate certain code blocks as atomic. Programmers using a TM often would like to access the same data both inside and outside transactions, e.g., to improve performance or to support legacy code. In this case, programmers would ideally like the TM to guarantee strong atomicity , where transactions can be viewed as executing atomically also with respect to non-transactional accesses. Since guaranteeing strong atomicity for arbitrary programs is prohibitively expensive, researchers have suggested guaranteeing it only for certain data-race free (DRF) programs, particularly those that follow the privatization idiom: from some point on, threads agree that a given object can be accessed non-transactionally. Supporting privatization safely in a TM is nontrivial, because this often requires correctly inserting transactional fences , which wait until all active transactions complete. Unfortunately, there is currently no consensus on a single definition of transactional DRF, in particular, because no existing notion of DRF takes into account transactional fences. In this paper we propose such a notion and prove that, if a TM satisfies a certain condition generalizing opacity and a program using it is DRF assuming strong atomicity, then the program indeed has strongly atomic semantics. We show that our DRF notion allows the programmer to use privatization idioms. We also propose a method for proving our generalization of opacity and apply it to the TL2 TM.

Modular transactions

“…Therefore, for mixed-race free programs in the implementation model, SC-LTRF holds. Khyzha et al [22] establish a similar result for global TRF.…”

“…Our results in §5 show that our model does not suffer from "optimization obstruction" [35]. Prior work, e.g., [22,34,35], requires that programmers place quiescence fences in order to guarantee safe privatization. Our low level model illustrates the correctness criteria for such techniques.…”

“…For TRF programs, SC-TRF implies opacity [15,16], which generalizes SC-DRF to include aborted and live transactions. SC-TRF is a conditional form of operational refinement: for TRF programs, "every behavior a user can observe of a program using a TM implementation can also be observed when the program uses an abstract TM that executes each block atomically" [22].…”

“…We describe how to compile our model to x86 and ARMv8 ( §6). We are inspired by Khyzha et al [22], who followed the same agenda for global races using a model similar to our implementation model; we discuss related work in §7.…”

“…Implementation-Level Reasoning. Most prior work relies on programmers to place quiescence fences to guarantee safety [22,27,[34][35][36]. We connect our high-level model to this previous work by developing a lower-level implementation model that includes explicit fences.…”