Condition Variables and Transactional Memory : Problem or Opportunity ?

Condition variables complement locks by allowing a program to specify the order of execution. They have been in use, largely unchanged, for three decades and have proved to be a robust and scalable synchronization mechanism. However, most transactional memory (TM) systems provide no complementary mechanism. While new synchronization constructs have been proposed for TM, it seems prudent to support condition variables with transactional memory at least until other proposals prove themselves to be as robust and enduring. We present an examination of condition variables and transactional memory. We show that straightforward conversion of lock-based condition variable mechanisms to transactions may be incorrect for some TM systems. We present two condition variable designs for transactional memory that require little from the underlying TM system yet can express common usages of conditional waiting. Both versions impose minimal requirements on the TM system and neither requires knowledge of how TM is implemented or modifications to the TM system. To adapt condition variables to transactions, we split the wait operation into two operations, preparing to wait transactionally and completing the wait after commit. In the first design, we defer signaling until after commit to prevent races between signalers and the waiters they wake up. In the second, we signal speculatively before the transaction commits and depend on transactional conflict detection to prevent races. We show that both perform well on lock-based programs from the PARSEC suite converted to transactions.