Two Interfaces to the RSTM Transactional Memory System

Transcription

1 Two Interfaces to the RSTM Transactional Memory System David Eisenstat May 9, 2006 Abstract Software transactional memory is a promising new paradigm for concurrent programming. We explore the design of the application programmer interface to RSTM [MSH + 06] and propose language extensions to C++ that alleviate some of the unavoidable difficulties with the API. 1 The Transactional Memory Model 1.1 A Scenario Transactional memory was introduced by Herlihy and Moss [HM93] as a way to simplify concurrent programming. Herlihy and Moss proposed a hardware implementation; in a later effort, Herlihy et al. introduced DSTM [HLMWNS03], which provided transactional semantics without special hardware support. The differences between transactions and mutual exclusion, the usual approach to concurrency control, are perhaps best explained with a parable. Alice is a thrifty traveler in New York wishing to visit London. She needs a round-trip airline ticket and a hotel reservation, but she is unwilling to spend more than $2000. Bob is Alice s travel agent. He will negotiate with Carol, who represents an airline, and Dave, who represents a hotel. Carol and Dave will give Bob good deals only if he makes nonrefundable reservations. How should Bob make reservations for Alice? He could call Carol first and ask her how much an airline ticket will cost. He could then call Dave to ask how much a hotel reservation will cost. If the total is less than $2000, he purchases the hotel reservation and calls Carol back to buy the airline ticket. In a sedate market, this strategy will work. Unfortunately for Bob, the London travel market is not at all sedate, and Carol changes her prices constantly in order to maximize profits. If she were to raise her prices after Bob reserves a hotel room from Dave, Bob might find that he is unable to buy an airline ticket without exceeding Alice s $2000 budget. The money he spent on a nonrefundable hotel reservation is effectively lost. How can Bob avoid this problem? In an approach patterned after mutual exclusion, he can try to convince Carol to set aside a ticket and grant him indefinitely the option of buying it at the price she quotes. If Carol is willing to do this, Bob can buy a hotel reservation from Dave, confident that he will be able to purchase a sufficiently inexpensive airline ticket. Since this option amounts to a refundable ticket, however, she will almost certainly not be willing. Moreover, if Eve, Submitted in partial fulfillment of the requirements for a B.S. (Honors) in Computer Science Department of Computer Science, University of Rochester 1

2 a competing travel agent, should make her purchases in the other order, the following scenario becomes a possibility: Carol has only one ticket left, which she promised to Eve, and Dave has only one room left, which he promised to Bob. No one can make any progress! Another approach, which is analogous to transactional memory, is for Bob to interact with Carol and Dave through an arbitrator Trent with whom everyone has signed contracts. When Bob is about to book a travel package, he informs Trent, who starts a file on Bob. When Carol or Dave gives Bob a quote, they inform Trent, who adds the quote to Bob s file. Using Trent, Bob can finalize the quotes on his file at any time, but Carol and Dave can cancel their offers at any time. If Bob tries to make a purchase before he discovers that one of his quotes is no longer valid, Trent will cancel his purchase. Trent s role is to make guarantees about the process of purchasing, namely that a package is purchased either in total or not at all. 1.2 From Agents to Objects In the previous section, Alice and Bob together represent a thread executing a transaction, Carol and Dave represent objects shared between threads, and Trent represents the system providing transactional memory. In most transactional memory systems in which an object is the granularity of access, threads use the following procedure to make updates to shared objects. First, the thread informs the transactional memory system (henceforth abbreviated system) that it would like to begin a transaction. Once the transaction has begun, the thread may ask the system for read-only or read-write access to shared objects. The system either grants access, making a backup copy in case the thread requested read-write access, or it informs the thread that its transaction has been aborted. When the thread is done making updates to shared objects, it tells the system that it would like to commit. The system responds either that the operation was successful, in which case all of the updates become permanent, or that it was not, in which case none of the updates are made. At no time can a thread observe the partial effects of another thread s transaction. Continuing the example from before, we suppose that the available airline tickets are stored in one object, which we call A and the available hotel rooms are stored in object H. When thread B (for Bob) is purchasing a travel package, it requests read-only access on objects A and H to check the prices. If they sum to less than $2000, B upgrades its access to A and H and updates them to reflect a purchase. Suppose thread B opens (successfully requests access to) both A and H for writing and then is preempted. Another thread, say thread D, decides to change the prices of hotel rooms. D begins its own transaction, in which it requests read-write access to H and updates the prices. This is a conflict, since both B and D are trying to update H. The system, then, must prevent at least one of B and D from committing its updates. 1.3 Design Considerations The main requirement of a transactional memory system is to make it appear as though transactions are being run in sequence. This makes it easy to reason about transactional code, since the opportunities for race conditions are very limited. One implementation that satisfies this requirement is to use a single global lock to prevent two threads from performing a transaction at the same time. Although this is a correct implementation, it prevents threads that access disjoint sets 2

3 of objects from running in parallel, even though they will have no adverse effect on one another. For example, Carol and Dave can t change their prices at the same time. Another disadvantage of this implementation is that it is not obstruction-free [HLM03]. Informally, a system is obstruction-free if when all threads but one are stopped, the remaining thread will eventually make progress. Obstruction-free systems have some desirable properties: they cannot deadlock, and high-priority threads can never be blocked by lower-priority threads. With a single global lock, if a thread begins a transaction and is preempted before it can finish, all other threads have to wait for that thread to run again before they can begin their own transactions. Many existing software transactional memory systems, including RSTM, are nonblocking; Saha et al. [SATH + 06] and Ennals [Enn05] argue that it is not necessary for systems to be nonblocking and offers their own systems as evidence of the potential performance gains. One major source of overhead in software transactional memory systems is preventing inconsistencies between different objects. For example, if airline tickets and hotel reservations are always purchased together, objects A and H from the previous example should always register the same number of sales. Consider, however, the scenario where thread B opens A for reading and is preempted; in the meantime, another thread commits a purchase transaction. When thread B resumes and opens H for reading, the number of sales in H won t match the number of sales it observed in A. Although perhaps harmless in this example, some code may be adversely affected. In order to prevent this problem, the system must abort B when it requests access to H. There are two ways to do this in software: the first places the burden on B (B reads invisibly) and the second places the burden on the other thread (B reads visibly). When a thread reads an object invisibly, it must check to make sure that it has the most recent version of that object every time it requests access to another object. This incurs work quadratic in the number of objects read, which can be crushingly large for long transactions. When a thread reads an object visibly, it changes the object header to reflect the fact that it is reading. Other transactions that write the object assume responsibility for notifying the visible reader. Although this approach eliminates the quadratic overhead, it requires each reader to change the object s header. These changes cause contention in the memory subsystem for access to the cache line where the header is stored. Because of this overhead, some systems relax the consistency requirements and attempt to trap and recover from the errors that may possibly result. Others provide a way to release objects that have been read as a way for threads to inform the transactional memory system that their correctness no longer depends on the consistency of the released object. The final issue we consider is memory management. Because of the difficulty and overhead in interrupting threads in software between interactions with the transactional memory system, it is necessary to preserve old versions of objects until it is known that no transaction will use them in the future. For example, if thread B should access object A and another thread should successfully update A, the old version to which B was given access should not be reclaimed until after B finishes its current transaction (such as when it tries to open another object like H). This is exactly the sort of functionality provided by a garbage collector, and indeed many transactional memory systems have been implemented in garbage-collected languages. The rest of this paper is specific to R(S)TM [MSH + 06], short for Rochester (Software) Transactional Memory. It is implemented in C++, which is not usually garbage-collected, and thus its interface has special facilities for memory management. 3

4 //// provided by RSTM void stm::stm_init(); void stm::stm_dest(); BEGIN_TRANSACTION; END_TRANSACTION; template <class T> class Object<T>; /// T inherits from Object<T> template <class T> class Shared<T>; Shared<T>::Shared<T>(T*); const T* Shared<T>::open_RO(); T* Shared<T>::open_RW(); void Shared<T>::release(); Shared<T>* T::shared(); const T* T::open_RO(); T* T::open_RW(); void T::release(); Shared<T>* Shared<T>::shared(); void* stm::tx_alloc(size_t size); void stm::tx_free(void* ptr); //// optionally provided by user T* T::clone(void* ptr); void T::deactivate(); 2 The RSTM API 2.1 Design Considerations Figure 1: Summary of the RSTM API The most important goal in designing the RSTM API (Application Programmer Interface) was to make it as easy as possible to parallelize existing sequential programs. Other goals were to use the C++ type system to eliminate common user mistakes such as accessing an object in a way inconsistent with how it was opened and causing type errors by casting from void* or other generic types to the wrong type. RSTM was implemented by the authors of the paper [MSH + 06] in which it was first described. The author of this paper is responsible for much of the API design. 2.2 Basic Interface The RSTM API is summarized in Figure 1. It depends on the pthreads package to provide concurrent threads of execution. Any thread that makes use of RSTM functionality must first call stm init(). The matching function stm dest() frees all internal resources used by RSTM for the calling thread. Transactions are delimited by the macros BEGIN TRANSACTION and END TRANSACTION. In addition to denoting the enclosed code as transactional, these begin and end a new block respectively. 4

5 int attempts = 0; // declared and initialized previously // Shared<Counter>* mycounter; BEGIN_TRANSACTION; attempts++; // this will count failed transactions mycounter->open_rw()->increment(); // this will not // more transactional code END_TRANSACTION; Figure 2: Roll-back Effects The transaction will be repeated until it is successfully committed. In the event of a failed transaction, modifications to shared objects will be erased but all other changes to memory will be preserved. See Figure 2 for an example of this behavior. The designers of RSTM, which include the author, believe it is desirable because it allows transactions to learn from previous outcomes to improve performance. Shared objects of type T have C++ type Shared<T>. The sole constructor for Shared<T> takes one argument of type T*, a pointer to the object to be shared. RSTM takes responsibility for any object passed to this constructor; the destructor of the Shared<T> will deallocate this object. Once an object has been passed to the constructor, it should never be accessed directly again. In order to use Shared<T> a class T must inherit from Object<T>, which provides methods and member variables used internally by RSTM and duplicates some functionality available by calling the corresponding Shared<T>. Although it may seem strange for a class to inherit from a template class instantiated with its own type, this construction is valid C++, and it allows T to inherit methods with return types T*. Shared<T> has two methods that allow transactional access to the enclosed object; threads may not call these methods outside of a transaction. The open RO() method requests read-only access and returns a const pointer to the most recently committed version of the enclosed object. Because the C++ type system prevents writes to objects through const pointers, all reading threads can and do share a copy of the object. The open RW() method returns a pointer to a fresh copy of the most recently committed version of the object. If the calling transaction later commits, this copy will become the new version. If it does not commit, the copy will be automatically reclaimed. Both of these functions may throw an Aborted exception to indicate that RSTM has aborted the calling transaction. This exception is caught and handled by a catch statement inside the END TRANSACTION macro. Because a Shared<T> and the T it encloses are conceptually the same object, all RSTMprovided methods of Shared<T> are available from T and vice versa. Moreover, T provides (through Object<T>) a shared() method that returns a pointer to the Shared<T> object wrapping it. In writing transactional code, it was convenient to extend the open RO() and open RW() methods to be callable on NULL (in which case they return NULL). It is inconvenient to have two sets of variables, and to keep everything as a Shared<T>* without a compiler that eliminates redundant calls is wasteful. See Figure 3 for an example. This behavior is made possible by non-virtual methods, since C++ does not need to look up the correct method (and in doing so, dereference the object pointer). 5

6 // Shared<ListNode>* node; // node may or not be NULL const ListNode* node_r = node->open_ro(); // node possibly NULL! // node_r is NULL if and only if node is NULL if (node_r && node_r->val == 42) {... Figure 3: Opening NULL Pointers 2.3 A Shared Linked-List The code shown in Figure 4, which performs insertion into a sorted singly-linked list, demonstrates much of the RSTM API. To avoid special case code, the head node does not contain a value. As the list is traversed (variable curr), a pointer to the previous node is kept (variable prev). When the insertion point is found, prev is opened for write and modified to point to a new node, newnode, with value val. newnode, in turn, is made to point to curr, whose shared pointer is recovered with the shared() method. Although it might not be apparent on a first glance, this code makes use of the fact that open RO() can be called on a NULL object, as will happen when val is inserted at the end. 2.4 Advanced Features The release() method, called on an object opened for reading, informs RSTM that the correctness of the transaction no longer depends on that object remaining the same. The potential concurrency of the insertion code in Figure 4 can be greatly improved by uncommenting the line with the release() invocation. In general, it is difficult to support the use of operations with side-effects beyond the STM system in transactions. A typical such operation is prompting for and receiving user input. The reason transactional systems cannot cope is that a transaction that performs such an action is not guaranteed to complete successfully. In the special case of undoing accesses to the memory allocator, there is a straightforward solution. The tx alloc() and tx free() methods work like regular malloc() and free() except when they are called from inside a transaction. In that case, tx alloc() will ensure that any allocated memory will be freed if the transaction aborts. Similarly, tx free() waits until the transaction commits actually to perform the free and does nothing otherwise. The extent of an object intended by the programmer may include more space than C++ would automatically allocate for that object. For example, the implementor of a hash table that stores its buckets as linked lists might want the granularity of access to be entire buckets, not just the head node. To accommodate this usage, RSTM uses the clone() method of T to make a copy of the object; by default, this method is inherited from Object<T> and uses the copy constructor. Programmers can override this method to return a deep copy of the object (i.e., a copy that shares nothing with other copies). One of the consequences of a transactional programming model is that there will often be multiple contemporary copies of an object. Worse, these objects may have overlapping lifespans. 6

7 class ListNode : Object<ListNode> { public: int val; Shared<ListNode>* next; ; void insert (Shared<ListNode>* prehead, int val) { BEGIN_TRANSACTION; // find the insertion point const ListNode* prev = prehead->open_ro(); const ListNode* curr = prev->next->open_ro(); while (curr!= NULL && curr->val < val) { // can release here with // prev->release(); prev = curr; curr = prev->next->open_ro(); // insert val ListNode* newnode = new ListNode(); newnode->val = val; newnode->next = curr->shared(); prev->open_rw()->next = new Shared<ListNode>(newNode); END_TRANSACTION; Figure 4: Insertion into a Linked List 7

8 To provide flexibility, RSTM will not call the destructor of an object when there is another clone still active. Instead, the deactivate() method will be called. Programmers who want to specify custom behavior for deactivation (such as deallocating extra storage allocated during a custom clone() call) should override this method. 2.5 Interfaces to Other STM Systems The first STM system that allowed transactions to access dynamically determined memory locations was DSTM [HLMWNS03], implemented in Java. DSTM and its descendant ASTM [MSS05] share the same interface. The basic interface to RSTM owes much to DSTM, but it makes heavy use of the expressive C++ type system (primarily templates and const pointers) to avoid casts and detect many more problems at compile-time. DSTM, by contrast, requires the programmer to cast values of type Object to their correct type. FSTM [Fra03], implemented in C, suffers some of the same type-safety drawbacks as DSTM, as it uses void pointers the way DSTM uses type Object. Moreover, the API call to begin a transaction returns an opaque transaction handle that must be passed as a second parameter to open calls. There are some arguments for making the API work this way; it prevents programmers from performing transactional operations outside of transactions and gives more flexibility in binding transactions to threads. The big drawback, however, is that programmers must ensure that transaction handle is available wherever it is needed. Moreover, having one transaction per thread does not seem to be a limitation in practice. By contrast, STM Haskell [HHMPJ05] is very type-safe, making use of Haskell s type system to ensure that transactions not only cannot have type errors but also cannot perform operations that have side-effects outside of the STM system. SXM, written in C#, incorporates some ideas from STM Haskell. The novel feature of SXM is that it makes use of runtime reflection to open objects automatically. Although this is undeniably convenient, the C# runtime does not currently detect and remove redundant open calls, which imposes a performance penalty. 3 Language Support 3.1 Problems with the API As it demonstrates the RSTM API, Figure 4 also highlights some shortcomings of that API. Perhaps the biggest shortcoming, common to all of the systems in this class, is that programmers are required to split their code into transactions and annotate shared data. In the author s experience of parallelizing micro-benchmarks of a few hundred lines or less, this has been relatively straightforward; but it seems likely that larger programs will require a disproportionately larger amount of effort. This is a hard problem that we do not address here. There are, however, some shortcomings that are more easily addressed. First, every access to shared objects has to be made explicit with an open call. The alternative is to provide an implicit conversion, in which case neither the programmer nor many compilers, absent modifications, can eliminate redundant open calls. Second, programmers often have to annotate object methods as const when applicable, since open RO() returns a const pointer. Although these annotations are desirable even in sequential code, they are frequently omitted in practice. A better solution would be to delay opening the object on which a method is called, but it seems impossible to do this automatically in C++. Third, programmers are occasionally required to convert a T* to 8

9 a Shared<T>*. In theory, this could also be solved by providing an implicit conversion, but in practice gcc (and possibly other compilers) require explicit typing information to resolve conflicts such as when a T* is used as a boolean value and the compiler cannot determine which conversion to bool to use (even though it doesn t matter). 3.2 A Small Extension to C++ In this spirit, we propose a small language extension to C++. There are three new keywords: shared, atomic, and release. The shared keyword is syntactic sugar for the Shared<T> template type. Thus type shared T* becomes type Shared<T>*. It also informs the compiler that the special implicit conversion rules described below are to be applied. The old constructor for Shared<T> is replaced by a constructor for shared T that allocates a T. The syntax is shared T(...), where... denotes the arguments of the T constructor. This constructor eliminates a safety problem with the old one that was tolerated for usability reasons: there is no way in plain C++ to provide convenient access to all of the constructors for a given class. The atomic keyword is used to specify that the following block be executed transactionally. It replaces the BEGIN TRANSACTION and END TRANSACTION macros. As with the macros, the contents of an atomic block are performed repeatedly until success. The (existing) keyword break may be used to exit an atomic block, and the keyword continue restarts the transaction. To eliminate the need for complicated inter-procedural analysis, functions called from an atomic block are not automatically considered to be in an atomic context. These functions must have their own atomic block. It is permissible to nest atomic blocks. The release keyword takes the place of the old release() method. The promotion rules are simple and work as follows. Inside of an atomic block, open calls are inserted automatically when a term of type shared T appears where a term of type const T or T is needed, Outside of an atomic block, this raises a semantic error. No equivalent of the shared() call is provided. The linked list example, revised to use the language extension, is shown in Figure 5. After compiling away the language extensions as a source-to-source compiler would, the result is what is shown in Figure 6. Compared with the code in Figure 4, the Figure 6 code makes a redundant open call every time through the while loop. It would be a straightforward task, however, to adapt the common subexpression elimination phase of a compiler to remove redundant open calls, since within a given transaction, repeated open calls do not have any effect 1. The author has built part of a source-to-source compiler for a subset of C++ with the above extensions. The proposed extensions are particularly amenable to a source-to-source approach because aside from code improvement, all necessary adjustments to the source can be made locally on the basis of typing information. References [Enn05] Robert Ennals. Software transactional memory should not be obstruction free. rennals/notlockfree.pdf, [Fra03] Keir Fraser. Practical lock freedom. PhD thesis, Cambridge University Computer Laboratory, Also available as Technical Report UCAM-CL-TR Of course, if an object is opened, released, and then accessed again, it must be reopened. 9

10 [HHMPJ05] Tim Harris, Maurice Herlihy, Simon Marlow, and Simon Peyton-Jones. Composable memory transactions. In Proceedings of the ACM Symposium on Principles and Practice of Parallel Programming, to appear, June [HLM03] Maurice Herlihy, Victor Luchangco, and Mark Moir. Obstruction-free synchronization: Double-ended queues as an example. In Proceedings of the 23rd IEEE International Conference on Distributed Computing Systems, May [HLMWNS03] Maurice Herlihy, Victor Luchangco, Mark Moir, and III William N. Scherer. Software transactional memory for dynamic-sized data structures. In PODC 03: Proceedings of the twenty-second annual symposium on Principles of distributed computing, pages , New York, NY, USA, ACM Press. [HM93] [MSH + 06] [MSS05] [SATH + 06] Maurice Herlihy and J. Eliot B. Moss. Transactional memory: Architectural support for lock-free data structures. In Proceedings of the 20th International Symposium on Computer Architecture, pages IEEE Computer Society, May Virendra J. Marathe, Michael F Spear, Christopher Heriot, Athul Acharya, David Eisenstat, William N. Scherer III, and Michael L. Scott. Lowering the overhead of nonblocking software transactional memory. Technical Report TR893, University of Rochester, Computer Science Department, March Virendra J. Marathe, William N. Scherer III, and Michael L. Scott. Adaptive software transactional memory. In Proceedings of the 19th International Symposium on Distributed Computing, Cracow, Poland, September Bratin Saha, Ali-Reza Adl-Tabatabai, Richard L. Hudson, Chi Cao Minh, and Benjamin Hertzberg. McRT-STM: a high performance software transactional memory system for a multi-core runtime. In Proceedings of the 11th ACM SIGPLAN symposium on Principles and Practice of Parallel Programming, pages , New York, NY, USA, ACM Press. 10

11 class ListNode { public: int val; shared ListNode* next; ; void insert (shared ListNode* prehead, int val) { atomic { // find the insertion point shared ListNode* prev = prehead; shared ListNode* curr = prev->next; while (curr!= NULL && curr->val < val) { release prev; prev = curr; curr = prev->next; // insert val shared ListNode* newnode = new shared ListNode(); newnode->val = val; newnode->next = curr; prev->next = newnode; Figure 5: Insertion into a Linked List in C++ with Language Extensions 11

12 class ListNode : Object<ListNode> { public: int val; Shared<ListNode>* next; ; void insert (Shared<ListNode>* prehead, int val) { BEGIN_TRANSACTION; // find the insertion point Shared<ListNode>* prev = prehead; Shared<ListNode>* curr = prev->open_ro()->next; while (curr!= NULL && curr->open_ro()->val < val) { prev->release(); prev = curr; curr = prev->open_ro()->next; // and here // insert val Shared<ListNode>* newnode = new Shared<ListNode>(); newnode->open_rw()->val = val; newnode->open_rw()->next = curr; prev->open_rw()->next = newnode; END_TRANSACTION; // open here Figure 6: Linked List Insertion After Source-to-Source Transformation 12