TMunit is a testing tool for Transactional Memories (TMs). It currently supports TinySTM, TL2, WSTM, SwissTM and RSTM. More specifically, TMunit achieves three goals:
- Reproducible unit-test: providing high level domain-specific language to write workloads and tests easily. The workload is represented by a series of operations encapsulated in transactions encapsulated, in turn, in threads. A test consists in executing a schedule, a predetermined interleaving of these concurrent operations, and in checking whether an assertion holds, or if an invariant remains true during the execution.
- Transactionalization: converting critical sections of lock-based application traces into transactions. Testing TMs require to use realistic multi-threaded workloads. That is why TMunit can transactionalize and run existing parallel applications traces.
- Benchmark: recording the performance statistics (throughput, commit-abort ratio, etc.) of a TM when executing dedicated workloads. Performance statistics are made precise by automatically converting the high-level workload specification into C code, thus minimizing the benchmark overhead.
TMunit executes a workload on a dedicated TM. This workload corresponds either to a real trace taken from an existing application or to a synthetic description written in a domain-specific language. TMunit can either execute this workload dynamically or convert it into a C program to reduce the runtime overheads. TMunit also records performance statistics and test results. A test is modeled as an automaton performing transactional operation calls through the underlying TM. TMunit can use two different automata, depending on whether the configuration file is dynamically interpreted or translated into a C program. The user chooses the execution mode. If desired, the execution of either automaton may output a trace of the execution and detailed performance statistics. TMunit uses an abstract TM interface to map transactions on the underlying TM implementation. We have successfully tested it with TinySTM and TL2 implementations but any wordbased TM can be straightforwardly supported. Note that the TM can be linked as a dynamic library and, hence, no recompilation of TMunit is necessary when testing a new TM.
Sample TMunit Specification
As an example, the following specification tests if a dirty reads happens while a TM executes a very simple workload. On the left-hand side, transaction T1 updates the same location x twice while transaction T2 concurrently reads location x. Since each transaction should appear as if it were executed atomically, it should not be possible to have y = 1. This would correspond to a dirty read of location x by T2. Observe that, if we just require that two threads execute T1 and T2 concurrently on a TM, the dirty read may well not occur at runtime. To test appropriately that the TM avoids this problem, one must specify a certain interleaving of conflicting operations. On the right-hand side, we show the TMunit specification of a dirty read unit test. The interleaving of the transactions is defined in a schedule that enforces the read operation of x to occur between the two write operations of T1. The invariant checks, in the context of T2, whether this specific schedule leads to the dirty read problem (y = 1). Such a unit test language specification is of crucial importance for testing TM behaviors in specific situations, notably in scenarios with concurrent transactional and non-transactional accesses.
Derin Harmanci, Université de Neuchâtel, Switzerland (contact:)
Pascal Felber, Université de Neuchâtel, Switzerland
Vincent Gramoli, EPFL and Université de Neuchâtel, Switzerland
Martin Süßkraut, Dresden University of Technology, Germany
Christof Fetzer, Dresden University of Technology, Germany