Shared publicly  - 
Technology: Transactional Memory

TM is clearly gaining steam in the sense of getting mainstream hw implementations.

In a nutshell, TM is a glorified retry loop, treating reads and writes to a (smallish) region of memory as a transaction, giving lockless access and updates to complex data structures (and good scalability) in the best case and offering rollback and exception handling (fallback to locking) in the worst case - key bits of this implemented in hardware, sometimes pushed down to the memory controller level.

One aspect I have not seen stressed is that there's a psychological advantage to TM: traditional locking has to be correct, while with TM most programming mistakes in concurrency management will slow the code down - but not break it.

In a more abstract sense this is the main virtue of Java as well (trading performance for pointer safety, amongst other things) - and Java and its offspring are an uncontested success story.

This was the main virtue of x86 and CISC as well. (I should add MESI and HTML to the list as well.)

What marks all of these technologies is that there were "technically superior" alternatives to them available in the early days of those technologies, still those alternatives eventually died.

Often the reason behind this seemingly imperfect and "unjust" selection process is that programming is to a large degree psychology:

Good programmers know and are able to use technology very well.

The very best, "out of this world" programmers I know are those who (beyond having chosen the right parents to get the right brain structure) also know themselves and their own limitations very well and are able to control that aspect.

Thus good hw and sw design has to consider the human condition and has to consider psychology.

"Easy to use" alone is not enough - it is also often counter-productive in programming because the world around us is complex, thus hiding natural complexity while trying to map it is really just kicking the can down the road, at a cost.

"Being forgiving to human mistakes" is the key trait IMO.

This is the driving principle behind lockdep (the kernel's locking correctness validator) as well, and lockdep is by all means a success story as well, in the Linux kernel universe.

(Btw., and somewhat paradoxically, that's the reason why I still don't see much advantage in using transactional memory in the Linux kernel itself, if both TM and basic locking instructions are implemented similarly fast in hw: the combination of locking + RCU with strong validators is working well right now.)

It's still a bit early to tell, but TM might have gotten the human psychology aspect right, so I'd not be surprised if it gained traction in a similar fashion to how Java gained traction.

Inspired by Paul E. McKenney's recent post about TM:
Łukasz Mierzwa's profile photoAndrey Moshbear's profile photoPaul McKenney's profile photoMike Anderson's profile photo
Java has a dark side though: the price you pay for the convenience of not having to deal with pointers and memory allocation is the garbage collector. And while for a lot of things that's not a problem, if you do things wrong it becomes intolerable just at the point where you can afford it least.

I think TM has a similar dark side. It doesn't eliminate lock failures, and when things fail the retry process hits you really hard. Plus you have to think in terms of transactions to really make it work, in much the same way you have to think in terms of parallel threads of execution to really make hardware parallelism work. If a programmer can do that they're going to be able to really make it strut it's stuff, but if they can't it's going to just turn into a train wreck and a mess of heisenbugs.
Dmitry: The thing that I could not bring myself to say in my livejournal posting is that the TM people are applying transactions to in-memory operations just as the database people are moving away from transactions -- see the numerous NoSQL projects. I also cannot help but point out the mid-70s view that looping constructs were impossible to think about -- people use loops now, and they will be continuing to use threads in the future. It is a cultural thing: (1) the expectation that it is not all that hard will eventually fall into place and (2) as more people become proficient with all types of concurrent technologies, better ways to explain them will arise.

That said, I do see HTM and STM as being potentially quite useful in some important cases despite their limitations.
+Ingo Molnar One reason that I remain skeptical that TM will be to concurrency what garbage collectors have become to memory management is TM's fraught relationship with non-idempotent operations such as I/O. In contrast, a garbage collector does not restrict what you do with its memory as long as you maintain at least one reference to it.

Again, please note that I do believe that TM will prove useful. It is just that I do not believe that it will prove to be a concurrency panacea.
+Dmitry Belenko By "moving away", I meant "use less", not necessarily "eliminate entirely". From what I can see, the NoSQL projects require that updaters use transactions, but allow readers to dispense with them. And the "weakly atomic" TM implementations open the door to the same sort of behavior. However, from what I understand, all of the commercially available HTMs are strongly atomic. Relaxing the strict serializability requirements where appropriate can be hugely beneficial.

And I do not share your pessimism on threading -- it is just a matter of creating and using abstractions appropriate to the problem at hand.
Here's an upside to Intel's TM extensions to x86: it would be easier to write parallel code in asm.
And frankly, that's about all I see there.
+Andrey Moshbear I am a bit more positive on the various HTM mechanisms, including Intel's. They are useful in C as well as assembly for update-heavy in-memory data-structure access and update. No I/O, system calls, etc. And no debugging, from what I can see, though I would guess that debugging will be addressed, perhaps by substituting STM for HTM.

An update-heavy red-black tree is the prototypical HTM example because updates are almost always non-conflicting, but it is quite difficult to partition the data structure to use locking, and the update-heavy part prevents RCU from doing much for you.

So HTM doesn't come close to the TM hype, but it should nevertheless be quite useful.
Add a comment...