IBM's new transactional memory: make-or-break time for multithreaded revolution | Hacker News Reader

IBM's new transactional memory: make-or-break time for multithreaded revolution

arstechnica.com

26 pointsevo_918 comments

This is a question, not a criticism: Does IBM have any plans for addressing that little parenthetical about transactions that include unrollbackable side effects that have totally scuppered all previous software STM efforts except Clojure's and Haskell's? Moving the same primitives we've experimented with in software down to hardware will have the same resulting failure, only faster. Unconstrained side effects and STM do not seem to go together, and the problem is a semantic one, not a hardware one; even if we stipulate instantaneous execution of the STM code it still basically didn't work. Is there a plan for this?

If you're using a try-commit-retry pattern (i.e. transactional memory), and the code using that pattern can't actually be rolled back and retried, then the code is wrong. It's just as wrong as if it were to dereference a null pointer or read invalid memory.

I'm not familiar with existing transactional-memory systems - but I'd guess the issue there is due to them not actually supporting batching all the side effects into a single transaction, which seems to be something that would be very doable in hardware.

"and the code using that pattern can't actually be rolled back and retried, then the code is wrong."

Well, yes, sure, that's easy to say, but the problem there is when your base language has no way of detecting mutations that can't be rolled back, you can't help but write wrong code. You've been doing it since the day you picked up your first programming language, after all. And in theory, C arrays are perfectly safe because you will always pass around their lengths and check the length every time you so much as glance at the array, but in practice it's hopeless and the only practical solution for mere mortals is Don't do that. STM actually suffers from this even worse because if you actually want to take advantage of the composition promises (and if you aren't getting that why bother with STM in the first place), it only takes one bad case in one block of code, with no feedback to the programmer that an untracked effect has occurred at any point, to bring the whole thing down. One of the whole points is that you can write transactional code that calls other transactional code and it's all supposed to Just Work in a way lock-based code can't be composed together, so a single transaction may run all over the program just like a single function call can.

I can't hardly get my coworkers to properly encode their HTML, and you expect me to teach them about managing effects in a language that doesn't even acknowledge they exist as a distinct category of things?

You can solve this by adding a concept of "effect" to your language, as Haskell does... but once you do that, you no longer have the same language. Not even close. None of the old libraries will work, more semantics will have to be tweaked, the change will ripple everywhere in both semantics and probably syntax, new coding patterns will have to be learned (and worse, unlearned!)... unless someone's come up with a really big breakthrough that everybody up to this point has missed.

It's not a hardware problem, it's a semantic problem.

It seems like your complaint is "shitty programmers will still do it wrong".

Does this "solve" the concurrency problem so that the most craptastic of copy-pasters can write high-performance concurrent code? Hell no. But it never pretended to in the first place, so that's pretty much irrelevant.

It's like saying that doing graphics processing in dedicated hardware is bad because a lot of programmers are awful at coding 3D graphics.

Even if you look at this just as a convenience for compiler writers, this would significantly improve the performance for anything that does do transactional memory properly.

It's also a very useful primitive for people writing shared data structures, like concurrent hash tables or multiple-producer, multiple-consumer priority queues.

The problem with C arrays is not that shitty programmers get them wrong; the problem with C arrays is that only programming gods walking amongst men get them right.

Managing effects in a language without any support for it, and decades of work put into making effects easier to implicitly apply without even having to think about it, is at least as hard.

There's more to the programming difficulty scale than "shitty" and "competent" and it's not a good idea to count on any programming technique that can only be used by the gods amongst men... even if you are one! (Writing raw string-concatenation-based HTML output safely is another example. No, you can't do it correctly in a large code base without help. Even if you are that smart, you aren't that superhumanly diligent.)

I think you misunderstand STM. STM is used to group and apply a few micro-operations, within a single function, but not many or over multiple functions, certainly not over multiple modules. It is not really for rebounding from exceptions in the general sense, as transactions are used in an RDBMS. It's more to keep the system in a stable state, something locks are usually used for in multi-threaded programming. Just as locks are best applied as fine-grained as possible, so is STM.

The goal of STM is to be composable, unlike locks:

http://research.microsoft.com/en-us/um/people/simonpj/papers...

The title of the paper is "Compsable Memory Transactions", and here's an excerpt:

As we show, STM can be expressed particularly elegantly in a declarative language, and we are able to use Haskell’s type system to give far stronger guarantees than are conventionally possible. Furthermore transactions are compositional: small transactions can be glued together to form larger transactions.

Sure, just as you'd understand a library or function to be "thread safe" it could be considered "transactional." I'm saying STM is to be used in as fine a grain as possible, even if it's composing "larger grains." Just as thread-safety doesn't mean entering a shared, global critical section at the beginning of every function, STM doesn't mean that every block of code should be wrapped in a transaction. STM should really only be applied to writes that would cause the system to be in an improper state if partially applied.

I'm not sure I agree. Reads also need to be in transactions in order to prevent deadlocks. I think the paper I linked is pretty accessible, so it's worth a read.

I agree that most of your program should be pure, though, but that's just a good practice in general, not something tied to transactional memory.

In an object-oriented language, I think it's unrealistic to assume that transactions will not cross module boundaries.

STM is pointless if it only works on just the tiniest possible transactions. Wrap a lock around the tiny transactions and call it a day. Without the composability, STM has no appeal.

Yes, you still don't want long-running transactions and you will seek to minimize them, but the entire point is that you can write an STM action that may cross a few modules coming from different authors and put a selection of such actions together, and one must only apply normal amounts of thought to such minimization instead of insane amounts of thought and effort.

It may be worth pointing out that I've made non-trivial use of the Haskell implementation. For Haskellers and Clojure programmers, STM isn't a pie-in-the-sky tech, it's a relatively straightforward library, because if you can manage effects or build it into your language very early (respectively), STM is almost boringly easy to implement. It's only hard (to the point of apparent impossibility) if you try to bodge it onto an existing imperative language.

In everything I've read, that's not an issue that really bothers anyone. The serious issues are performance (it's generally not very good) and the semantics can actually become just as tricky as locks (nested transactions can get surprisingly hairy, and you still need to know where to put them).

I work for IBM, but not on this.

This appears to be a very low-level, primitive implementation, so there's still room for an STM layer on-top of this. It isn't going to replace fully-baked persistent data structures, but it could certainly be used to accelerate them.

It's simply a way to jump back to a load operation if the following inverse store operation causes a conflict. The sauce is that multiple stores can be atomically committed in a single operation. This is effectively impossible to achieve without a lock of some kind on CPUs without HTM, and has major performance implications for multi-threaded code that has high levels of resource contention.

As is mentioned in the last paragraph of the article, this machine should give insight into the viability of hardware TM. Maybe it will be implemented in more common processors one day, especially as the number of cores increases.

I don't understand how this is new. Don't Haskell and a couple other languages already do this? My understanding is Haskell has been made to run a million transactions simultaneously, so it's performant.

Those do it on the software side, 'emulated'. This article is about getting it on the hardware; on the processor itself.

"Up until now, transactional memory research has mostly focused on software-based implementations. Real processors don't actually support transactional memory, so it has to be emulated in some way."

"BlueGene/Q moves transactional memory into the processor itself."

> I don't understand how this is new.

This is built on hardware. Haskel, Clojure and others have to emulate it with a much slower software implementation.

Reply on news.ycombinator.com