C++ transactional memory

Sometimes I feel like an archaeologist, and today I’ll share one of my findings: an old proposal for the C++ standard, N1613. It discusses transactions for C++. Yes, you read that right—transactions. The good news is, this is partially supported by GCC, though not fully.

What are transactions?

A transaction typically involves one or more actions that either complete successfully together, or none of them have any side effects. If several variables are updated within a transaction, either all variables get new values, or they all retain their old values.

What’s inside the proposal?

The proposal introduces the following language constructs:

• Global synchronization for specified code blocks.
• The ability to roll back changes applied during a transaction.

With transactions, you get a total order of transaction execution and the ability to roll back changes. All transactions execute in a global order, one after another, eliminating the need for mutexes or other synchronization mechanisms. This behavior is illustrated below:

What do I need to get started?

This feature is partially implemented in GCC since version 4.6. You'll need that version of the compiler, the `itm` library, and the compiler flag `-fgnu-tm`. Below is an example of the CMake configuration:

Just synchronization

If you only need synchronization for a few operations across multiple threads, consider the new keyword `synchronized`. It marks a block to be synchronized, meaning each block with this keyword is executed in a global order, as if protected by a global mutex. This can be used to create a thread-safe counter without explicit thread synchronization, as shown here:

There are no restrictions on the operations within a `synchronized` block, so printing and other operations are allowed.

Atomic transactions

While synchronization is useful, what's more exciting is the ability to cancel applied modifications if a condition isn't met. Let’s say I have an array, and I want to assign the sum of all elements to each element. If the sum exceeds a maximum value, the operation is aborted, and all previously modified elements revert to their previous values.

To create a transaction block, use the `__transaction_atomic` statement. To roll back changes, use `__transaction_cancel`. In `calculateNext()`, the sum of the array is calculated and assigned to each element. If the sum exceeds the defined maximum, all changes are rolled back, and an exception is thrown:

The method `sum()` is marked `transaction_safe` to indicate that it can be used inside a transaction block:

One key point: `__transaction_atomic` blocks are globally synchronized, so there's no need for additional mutexes or atomics. However, there are some limitations:

• Functions called within a transaction must be marked as `transaction_safe`, or the compiler should deduce it.
• No assignment, initialization, or reading from `volatile` objects.
• No inline assembly (`asm`).

Additionally, you can't return values if a transaction is canceled, though exceptions can still be thrown to indicate a rollback.

Alternatives

For synchronization, you can use mutexes or atomic variables if you're dealing with individual types or small objects. This approach eliminates the global ordering requirement and allows for concurrent operations on unrelated variables, improving performance.

For rollback operations, there aren’t many alternatives, but custom solutions might be faster and impose fewer restrictions.

Performance comparison

Let’s compare the performance of this new feature against alternatives.

For a `synchronized` block versus a mutex implementation with 200,000 iterations:

• Transaction memory: 6.47201 ms
• Mutex: 2.74545 ms

For atomic transactions versus a mutex with an object copy that updates only if the condition is met:

• Transaction memory: 274.483 ms
• Mutex: 126.692 ms

Conclusion

You can find the source code in my repo: https://github.com/sqglobe/transaction-memory.

While transactional memory is an intriguing concept and opens up new programming paradigms, I personally would consider alternatives due to performance reasons, especially with the current software-only implementation.