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