Anyone who has had to write multithreaded code will know that one of the big problems with having multiple threads is ensuring that two threads do not modify the same data at the same time, or that one doesn’t read data that is being modified by another. The standard way of dealing with this of course is to use locks. Locks bring problems of their own though, with deadlocks and race conditions being common – difficult to debug and fix – problems.

One proposed solution is transaction memory, which employs the concept of atomic blocks of code that work in a similar way to transactions in databases. In other words, a snapshot of the data state is taken, then a series of memory reads and writes are processed and logged. Finally a lock is taken by the sytem, the data checked and – if no changes outside of the thread occurred – the logged changes are applied. Then the lock is released. If changes did occur, the whole lot is aborted.

Transaction memory has been around for a while, but purely as a research/ academic concept. Today though, Microsoft launched a new transaction memory blog run by the folks in Microsoft’s Developer Division’s Parallel Computing Platform product group. They plan to add an experimental transaction memory model to .NET. Whetehr this will ever go into production is still unknown, but it should be a great blog to watch for further developments in this area.