Rochester Software Transactional Memory

• Google Code Site
• Main
• License
• Download
• Building RSTM
• Programming with RSTM
• Applications
• STM Implementations
• STM Primer

Google Code Site

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.

What's new in Release 5?

STAMP Bindings

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 the libstamp directory for more information.

API Extensions

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.

• SSS Memory Semantics

  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 an 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

  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 nop 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 signal. halt_retry() should be used if retrying transactions could be present.

New STM Implementations

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.

• ET

  An extendable-timestamp based implementation similar to TinySTM. It supports eager and lazy write acquisition and eager (with eager acquisition) and lazy write versioning.

• Strict

  ET with support for SSS memory semantics.

• Flow

  ET with additional support for ALA/SFS memory semantics.

• SGLA

  An implementation that supports SLA memory semantics, as described in Menon et al. The implementation is based on their description of a pipelined commit structure.

• Fair

  An optimized lazy acquire, lazy versioning implementation that supports transaction priority for conflict resolution and starvation avoidance.

• TML

  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.

• TML + Lazy

  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.

• RingSW

  Uses bloom filters rather than a global orec table to track transactional read and write sets.

• Precise

  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.

New Applications

• hashing

  An extensible hashset benchmark used to test contention manager performance.

New Architecture

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.

What's new in Release 4?

What's new in Release 3?

What's new in Release 2?

What Platforms Are Supported

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.

License

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:

1. If your use of this software contributes to a published paper, please (1) cite our summary paper, which appears on this website, and (2) e-mail a citation for your published paper to .
2. If you redistribute derivatives of this software, please let us know, and either (1) ask people to register with us at this website or (2) collect registration information and periodically send it to us.

More Information

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

• contention management
• transaction scheduling
• inevitability and retry
• privatization and publication
• compiler optimizations for TM
• transactional memory semantics
• our RTM, AOU, and FlexTM hardware proposals
• transactional applications

You will also find information about

• lock-based synchronization
• nonblocking data structures

Acknowledgments

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.