An Analysis of I/O And Syscalls In Critical Sections And Their Implications For Transactional Memory

Abstract

Transactional memory (TM) is a scalable and concurrent way to build atomic sections. One aspect of TM that remains unclear is how side-effecting operations -that is, those which cannot be transparently undone by a TM system -should be handled. This uncertainty poses a significant barrier to the general applicability and acceptance of TM. Further, the absence of transactional workloads makes it difficult to study this aspectIn this paper, we characterize the usage of I/O, and in particular system calls, within critical sections in two large applications, exploring both the actions performed and the characteristics of the critical sections in which they are performed. Shared memory programs employing critical sections are the closest approximation available to transactional workloads, so using this characterization, we attempt to reason about how the behavior we observed relates to the previous proposals for handling side-effecting operations within transactions. We find that the large majority of syscalls performed within critical sections can be handled with a range of existing techniques in a way transparent to the application developer. We also find that while side-effecting critical sections are rare, they tend to be quite long-lasting, and that many of these critical sections perform their first syscall (and thus become side-effecting) relatively early in their execution. Finally, we show that while these long-lived, side-effecting critical sections tend to execute concurrently with many critical sections on other threads, we observe little concurrency between side-effecting critical sections.

Implementing and Exploiting Inevitability in Software Transactional Memory

“…Baugh and Zilles [1] have argued that transactions that perform I/O are likely to run a long time, and to conflict with almost any concurrent activity. This suggests that quiescence overhead will be an unimportant fraction of run time, and that there is little motivation to let anything run in parallel with an inevitable transaction.…”

“…Inevitability has been considered by several existing hardware or software TM systems [1], [6], [11], [15], [18]. With the exception of the hardware system of Blundell et al [3] and the software system of Welc et al, inevitability is generally assumed to preclude all parallelism-to require, in effect, a token that prohibits any concurrent transactions from committing.…”

Integrating file operations into transactional memory

“…A second approach allows non-I/O transactions that have no conflicts with the inevitable transaction that is in progress [3,5,11,26] to proceed. Transactions with side-effects (i.e.…”

“…the transaction is ready to commit) [28,29,30]. This approach demands that the developer reasons about the flow of the program and hence introduces a new source for bugs in the transactional application [26] and violates the benefits of implicit transactional programming.…”

StealthTest: Low Overhead Online Software Testing Using Transactional Memory

“…System Calls within StealthTest Transactions. Support for system calls within transactions [2,25] is an area of active research. Empirical evidence suggests that many system calls can be supported from within transactions.…”