What will it take for Transactional Memory to be viable?_问答_开发者

I've been doing some work on transactional memory and its viability for systems programming (databases, operating systems, servers, etc.). My own experience employing transactions, together with having seen how few communities use transactions in real code, has raised a question: What would convince you, a developer writing production code, to employ transactional memory in your work?

Would it be general adoption? High speed? Improved reliability? By how much?

For those that haven't seen them, memory transactions act like database transactions: operations proceed (apparently) in parallel, and if there is a conflict between two transactions (e.g. they both write the same value), then one or both of the transactions will be rolled back and restarted.

Transactional memory has a few benefits:

Reliability Complete freedom from deadlocks (e.g. wrong-order locking).
Performance Greater speed when there is low contention for locks.
Programmability Fine-grain concurrency control without many synchronization objects to manage.

Even assuming a correct, complete, and fast implementation of TM, however, there are known downsides to this primit开发者_Python百科ive when compared with locks.

Since transactions might execute several times, it is more difficult to predict performance except by empirical experiment.

Can we reproduce performance bugs?
There are some policy decisions that differ between correct implementations, e.g. What happens to a transaction that ends inside another transaction? Do we commit now, or do we wait?

Can we adequately understand the local effects of our code?
In order to support irrevocable behavior (e.g. sending the "fire missiles" command) in a transaction that is rolled back, the runtime becomes more complex.

Can we adequately understand the global effects of our code?

Lastly, as Software implementations will probably be the first to be used (there are already implementations in C, C++, Haskell, Clojure and Scala, to name a few), there actually is a performance problem. With moderate contention, software transactions come with a performance hit.

What is your performance budget? At what point do the benefits outweigh the potential costs?

I have done some experimenting with TBoost STM and it seems to be usable, though I would not be comfortable using it in a production product yet. The shift in thinking needed is significant though, so I doubt it will catch on unless it shows a compelling benefit in real applications.

I keep hearing that the future is in massively parallel computing as CPUs start to double in cores like they used to double in frequency. So far, 4- and 8-core desktops aren't really showing themselves to be useful for general workloads. I think we have a bit of a chicken-and-egg problem: adoption of parallel machines is waiting on software capable of taking full advantage, while mainstream development of highly parallel software is waiting for ubiquity of highly parallel hardware.

I think perhaps what's needed is an open-source software project to adopt an STM model for something like a web server. A successful project like that would be an excellent model and might help kickstart interest across the software industry by proving that STM is ready for the real world.

Several things:

1) The Software Transactional Memory (STM) System would have to be robust, reliable, and tested so that it actually works.

2) The performance overhead of an uncontested STM transaction should be comparable to the same routine with a uncontested lock.

3) The STM system must perform significantly better when multiple transactions are pending vs using a lock on contested resources.

I think that there are some criteria that A STM system must provide to user adoption:

Simplicity: The use of transactions is in theory more simple than using lock, but in practice it is not the case there will be no reason to use it.

Performances: The user can accept that the performances be a little bit slower than using locks, but not too much slower.

Interaction with non-transactional world: STM systems that work only on a transaction only world can not succeed for people that works in projects that need to work with a legacy system, or that has other constraints, that can be solved better using other paradigms.

Correctness: The user needs to be confident that the system s/he is using is correct on its foundations as well as in its implementation. Most of the current STM systems are not at the stage of a product, so people can suffer of unstable versions for a moment.

Debugging tools: The debugger tools must be adapted to this new paradigm (at least when the STM system is incorporated on the language), as debugging could be more complex when the same code is executed several times if there are conflicts.