Last article I covered my implementation of software transactional memory in C#. If you haven't read those articles yet, in brief, it's a technique where we can write efficient, thread-safe client code without using having to think about locks or events - all isolation, atomicity and signaling is handled by a small set of common routines.

I've presented this technique, and the code, as the realization of an idea that could be taken further - I'm pretty sure it's not ready for production code yet. In this final article, I'll give a link to the source, and cover some pros and cons of this technique.

The articles and source will be kept up-to-date on:

http://www.binarycomponents.com/Labs

But for convenience, here's links to everything so far:

Part 1: The Problems with Locking

Part 2: Atomicity and Isolation: That Reminds Me Of A Database

Part 3: Implementation

Source: TransactionalMemory.zip

Pros

• Safety: Transactional values must be accessed inside a transaction. This is enforced by a runtime check.
• No deadlocks: All locks are taken by the implementation, not the client code. Locks are taken in a strict order.
• No explicit communication: Communication is handled by the implementation; the client only needs to rollback and wake-ups are handled automatically and efficiently.
• Fine-grained locking: Only those locks which need to be taken are taken, and for as short a time as possible.

Cons

• Copy overhead: When values are first accessed, or a transaction committed, values are copied. This would be unacceptable for large data-structures.
• Re-execute overhead: Code blocks that rollback must be re-run. If the block performs significant processing, this would waste CPU time.
• No side-effect checking: Code blocks should be free of side-effects, but this cannot be enforced in C#.

Feedback

If you have any comments on this technique, please let me know. I'd be particularly interested if anyone uses it in "real" code, as opposed to my simple examples. Additionally, if you're able to overcome any of the "cons" listed, I'd like to know that too.

If you find any bugs, please do let me know, and I'll update the source. (Any bugs in the implementation will of course go to show how bug-prone normal locking techniques are).

Further Reading (And Listening)

If you're interested in multi-threaded coding techniques, you might find the following .NET-related projects and shows interesting:

• Joins Concurrency Library for C# 2.0
• C? (Comega)
• .NET Rocks! shows about concurrency: #241, #269