
IBM's new transactional memory: make-or-break time for multithreaded revolution - evo_9
http://arstechnica.com/hardware/news/2011/08/ibms-new-transactional-memory-make-or-break-time-for-multithreaded-revolution.ars
======
jerf
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?

~~~
jbri
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.

~~~
jerf
"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.

~~~
rbranson
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.

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

[http://research.microsoft.com/en-
us/um/people/simonpj/papers...](http://research.microsoft.com/en-
us/um/people/simonpj/papers/stm/stm.pdf)

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._

~~~
rbranson
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.

~~~
jrockway
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.

------
rbranson
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.

------
kristianp
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.

------
michaeldhopkins
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.

~~~
blaenk
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."

