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.
Here’s a question: what do you do if you have a batch of quad-core chips that have a dodgy core?
Answer: think up a silly name and sell them as triple-core chips!
AMD have recently announced that they are producing a new line of processors with a triple core to fill a gap in high-end desktop machines. This gives them the edge over Intel, who only offer 1,2 or 4 core. And apparently it really isn’t because they have a batch of dodgy quad-cores to sell off. I believe them… 😉
See AMD’s press release for more details