Transactional Memory: What's all the hubbub, Bub?

I feel like I've been bombarded by transactional memory ™ items all last week. First I read through an article published in the DEC/JAN 2006-2007 issue of ACM Queue titled "Unlocking Concurrency." Then, I see the HPCWire article that notes even Intel is looking into incorporating TM support in future platforms. After a little TM (transcendental meditation) of my own, I have a quick question: So what?

[Note to self: Why always so negative? Look for a topic that you can be positive about for a future blog post. And not something that you are positive you have negative feelings about, either.]

Before you click over to The Google or Wikipedia to find out what TM is, let me give you a quick description. Transactional memory is a system to ensure that updates to memory locations are performed atomically. Changes to data are encapsulated in transactions; transactions are committed to memory only when it is found to be safe to do so. If two or more threads/processes will change the same location, the transactions are rejected (no changes made to the memory image) and each thread must attempt to perform their transaction again until it succeeds. The atomicity of transactions can be enforced in software or hardware.

For multithreaded applications, guaranteed atomic updates of contended memory locations are an obvious good thing to have. My problem is not with the idea or the implementation of TM, it is with the programming aspect for TM. Both of the articles cited above have essentially the same example in code to demonstrate the advantages of TM with regard to multithreaded code. Specifically with TM, you can remove all of your explicit lock/unlock combinations to assure mutual exclusion and replace them with some form of "atomic" keyword that would be used to denote code that is to be considered a transaction.

After cleaning my glasses off to make sure I was seeing things correctly, I looked again at the examples given. Where was the advantage? It looked like I replace one set of mutual exclusion primitives with another. How is that better for the programmer? Sure, with TM, the execution should be faster than some kind of API lock/unlock calls, especially with support in hardware. (But, if you want faster synchronization, you use a CRITICAL_SECTION rather than a mutex.) Sure, you don't need to protect any of the read operations on contended data since that won't affect whether or not a transaction is allowed to be committed to memory. (Okay, that is an advantage to the programmer.)

Even if we had TM today, thread monkeys would still need to identify what data needed to be protected from concurrent updates and would still have to insert code to assure that those updates are done in an orderly fashion. And, of course, fancy new memory protection schemes won't do anything to help codes that aren't threaded or that don't have much concurrency to begin with. I'm all for TM and look forward to seeing how it evolves in future processors [I guess I can be positive], but I'm not convinced that it is going to make any kind of significant impact in a programmer's life.


The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.

Pour de plus amples informations sur les optimisations de compilation, consultez notre Avertissement concernant les optimisations.