The RSTM package is now available as a Google code project. We welcome your comments, suggestions, and contributions. Future releases will occur through the Google code mechanism.
The information hosted here is accurate with respect to the fifth release, and the initial Google code release. The STM Implementations and STM Primer pages will continue to be relevant, but we expect the RSTM-specific information hosted at the University of Rochester to become rapidly out-of-date.
The Rochester Synchronization Group is pleased to announce the fifth release of our Rochester Software Transactional Memory (RSTM) system. RSTM is a C++ package that now contains thirteen different STM library implementations, and a smart-pointer based API that allows consistent, high-performance, safe, and relatively transparent access to STM for user applications. RSTM is a research prototype, but has been successfully tested on a variety of benchmarks and applications.
This release contains the necessary components to build an STM library
compatible with the STAMP
benchmark suite. This can be used with any
of our word-based backends. See
libstamp directory for more information.
The good news is that the core RSTM API remains backwards compatible with our fourth release. This means that any applications written using the previous release version should continue to function correctly when compiled against most of the libraries in this fifth release.
We have extended the API to support two TM features that we have researched extensively since the fourth RSTM release.
The Selective Strict Serializability memory model semantics support the publication and privatization programming idioms by requiring that the programmer label transactions as acquiring (privatizing) or releasing (publishing). For more details see the linked paper.
With the RSTM API, a
release_fence() call indicates
that the next transaction is a publishing transaction, and
acquire_fence() indicates that the previous
transaction was a privatizing transaction. These calls should
immediately precede (release) or follow (acquire) the
corresponding transactional BEGIN or END macros, respectively.
Transaction priority serves as a contention management strategy that allows the user to determine which of two transactions should abort if they encounter a conflict. Lower priority transactions should defer to higher priority ones. This can be used to prevent starvation. It also encodes inevitability (a single TX with infinite priority), and can be used to support efficient retry.
setPrio(int) provides the interface to the priority
mechanism. The only runtime that currently implements this call
with anything other than a
is Fair. A side effect of the
priority mechanism is that special shutdown logic is needed in
case a transaction is suspended with retry, waiting for a
halt_retry() should be used if retrying
transactions could be present.
A major part of this fifth release is the inclusion of a number of different word-based STM backends, in addition to all of the backends available in the fourth release.
An optimized lazy acquire, lazy versioning implementation that supports transaction priority for conflict resolution and starvation avoidance.
An implementation that uses eager acquire, eager versioning, and a single global sequence lock. This is our lowest overhead TM implementation, but only allows a single writer or multiple readers to be active and valid at a time.
Uses the same single, global sequence lock as TML combined with a lazy acquisition, lazy versioning algorithm to allow readers to execute concurrently with a writer, up to the point where the writer commits. This provides more scalability than TML alone, while adding the overhead of lazy versioning for writers.
Uses bloom filters rather than a global orec table to track transactional read and write sets.
Extends TML + Lazy with value-based conflict detection as in JudoSTM. This allows transactions to validate and commit when a writer commits, providing more concurrency at the expense of logging and validation overhead.
An extensible hashset benchmark used to test contention manager performance.
The source structure of the STM library implementations has undergone a large change since the previous release. This will not affect users of the RSTM API, but will force those who have modified the existing libraries, or who have written their own libraries, to do a bit of work to bring their implementations up to the fifth revision style.
Please contact us if you have questions in this regard.
The primary platforms that we develop on are x86-32/Linux, x86-32/Darwin, and SPARCv9/Solaris10. These platforms should work well with gcc-4.2.4 or higher, though we have not tested extensively with gcc-4.4. We also use llvm-2.5 on the Linux and Darwin systems. Finally, we have x86-32/Windows support using Visual C++ 2008.
Other x86-32 variants of Unix, particularly FreeBSD and possibly Solaris 10, are likely to require only trivial fixes (if any) to compile and run. Similarly Linux on SPARC (with TSO userspace) should work well.
When browsing the RSTM source code you will see references to POWER fencing requirements. This is experimental POWER support and is not officially supported. This being said, we welcome reports and patches from POWER users. We expect full support for POWER in at least a couple of the runtimes with the next release. Likewise, there is some experimental IA64 support.
RSTM is released under the modified BSD license. We request, as a courtesy, that you register with us in order to access the download directory. This will allow us to alert you to future releases. (We will not use your name for any other purpose.) In addition, we ask that you adhere to the following requests if you download and use this software:
For more information about RSTM, you might want to view the Rochester Synchronization Group Publications List, which includes a full list of publications on RSTM and related topics, including
You will also find information about
This material is based upon work supported by National Science Foundation grants CCR-0204344, CNS-0411127, CNS-0615139, CCF-0702505, and CSR-0720796; and by donations from Sun Microsystems, IBM, Intel, and Microsoft. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation or any other sponsor.