Software Transactional Memory Library

General information

The software transactional memory (STM) library code provides several configurations and policies for implementing transactional memory (TM). A transaction performs a set of reads and writes to shared memory. The TM system, under certain conditions, guarantees that each transaction appears as if all of its reads and writes are performed atomically together in relation to other transactions.

For the current implementation, it is assumed that shared locations are either always accessed inside transactions or always outside transactions, and that transactions include only revocable operations without side effects, and hence can be safely undone and retried.

The STM implementations use metadata to synchronize access to shared locations accessed transactionally. Each shared location is associated with a metadata entry. A metadata entry serves as a version number tracking updates of associated shared locations, and as a lock protecting updates of these shared locations.

In general, at the beginning of a transaction, the thread sets private per-thread transactional status data and in some configurations read some global data. For transactional reads, the thread reads and checks the metadata corresponding to the target location and then reads the target location, and in some configurations, checks the consistency of the read set. For transactional writes, the thread records the target address and the value to be written, and in some configurations acquires the corresponding metadata lock. At the end of a transaction, the thread acquires the metadata locks corresponding to its write set if not already acquired, validates the consistency of its read set, writes the values to the addresses in its write set, releases the metadata locks, and finally resets its private transactional data.

The main design configuration issues are:


The default implementation uses the following policy and configuration options: In order to use different policies and configurations, add EXTRA_FLAGS settings to the make command. For example, to use an encounter-time acquire policy for transactional writes use the command: make all EXTRA_FLAGS="-DENCOUNTER_ACQUIRE" Some of the main configuration flags are:

XL compiler

The STM implementations support a low-level interface. The IBM XL C/C++ compiler for Transactional Memory available from IBM AlphaWorks ( uses this interface. Therefore, STM libraries built from this code release can be linked with user programs using that compiler without need to instrument individual reads and writes inside transactions. Programs need to use a high-level interface as specified in Note that the IBM XL C/C++ compiler for Transactional Memory runs on AIX systems only at this point, while the STM code runs on a variety of systems as noted below.

It is possible for other compilers to use this STM code, if they use the same low level interface described below.


The STM code runs on several platforms including AIX-PowerPC, Linux-PowerPC, and Linux-X86, and Linux-X86_64. The code may run on Solaris-SPARC but it has not been tested.


The low-level STM interface is defined in the file stm.h. The main functions and macros are:


The STM code can collect runtime statistics related to the inherent transactional characteristics of the program independent of the STM implementation, such as transaction sizes and frequencies, as well as the interaction of the program with the STM implementation specifics, such as Bloom filter matches, metadata locks acquired.

In order to build an STM library that collects statistics use:

make all STATS=on

Note that the performance of the STM library is significantly lower when collecting statistics is enabled.

Runtime statistics are categorized by static transactions. Each static transaction is identified by the file name and line number where it starts. Aggregate statistics are also generated.

In order to generate statistics files, the program needs to call the function stm_stats_out(). The program may call this function multiple times. Note that if the function is called by a thread while other threads are actively using transactions, then the statistics may be inconsistent as statistics of other threads may change while taking a snapshot of the statistics. Typically, calls to stm_stats_out should be at stable points of the programs such as at the end where only the main thread is active. In such cases, the statistics should be consistent.

The output files take the form stm_stats_tag<xx>_txn_<filename>_<lineno>.out for statistics per static transaction and stm_stats_tag<xx>_all.out for aggregate statistics. The tag indicates the number of times stm_stats_out has been called. The file name and line number indicate the associated static transaction. For example, on the second call to stm_stats_out, the runtime statistics for the static transaction starting at line 100 in the file foo.c will be included in the file stm_stats_tag02_foo.c_100.out.

A list of statistics is in the file stats.h. The following are some of the main statistics collected by the STM code: