On the Cost of Concurrency in Transactional Memory
- 533 Downloads
The promise of software transactional memory (STM) is to combine an easy-to-use programming interface with an efficient utilization of the concurrent-computing abilities provided by modern machines. But does this combination come with an inherent cost?
We evaluate the cost of concurrency by measuring the amount of expensive synchronization that must be employed in an STM implementation that ensures positive concurrency, i.e., allows for concurrent transaction processing in some executions. We focus on two popular progress conditions that provide positive concurrency: progressiveness and permissiveness.
We show that in permissive STMs, providing a very high degree of concurrency, a transaction may perform a linear number of expensive synchronization patterns with respect to its read-set size. In contrast, progressive STMs provide a very small degree of concurrency but, as we demonstrate, can be implemented using at most one expensive synchronization pattern per transaction. However, we show that even in progressive STMs, a transaction has to “protect” (e.g., by using locks or strong synchronization primitives) a linear amount of data with respect to its write-set size. Our results suggest that achieving high degrees of concurrency in STM implementations may bring a considerable synchronization cost.
KeywordsBase Object Read Operation Transactional Memory Progress Condition Software Transactional Memory
Unable to display preview. Download preview PDF.
- 2.Afek, Y., Morrison, A., Tzafrir, M.: View transactions: Transactional model with relaxed consistency checks. In: PODC 2010: Proceedings of the 29th Annual ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing (2010)Google Scholar
- 3.Alpern, B., Schneider, F.B.: Defining liveness. Information Processing Letters 21(4), 181–185 (1985)Google Scholar
- 6.Attiya, H., Guerraoui, R., Hendler, D., Kuznetsov, P., Michael, M.V.M.: Laws of order: Expensive synchronization in concurrent algorithms cannot be eliminated. In: POPL (2011)Google Scholar
- 9.Crain, T., Imbs, D., Raynal, M.: Read invisibility, virtual world consistency and permissiveness are compatible. Research Report, ASAP - INRIA - IRISA - CNRS: UMR6074 - INRIA - Institut National des Sciences Appliquées de Rennes - Université de Rennes I (November 2010)Google Scholar
- 13.Guerraoui, R., Kapalka, M.: On the correctness of transactional memory. In: PPOPP, pp. 175–184 (2008)Google Scholar
- 14.Guerraoui, R., Kapalka, M.: The semantics of progress in lock-based transactional memory. In: POPL, pp. 404–415 (2009)Google Scholar
- 15.Guerraoui, R., Kapalka, M.: Principles of Transactional Memory, Synthesis Lectures on Distributed Computing Theory. Morgan and Claypool (2010)Google Scholar
- 16.Hendler, D., Incze, I., Shavit, N., Tzafrir, M.: Flat combining and the synchronization-parallelism tradeoff. In: SPAA, pp. 355–364 (2010)Google Scholar
- 18.Kuznetsov, P., Ravi, S.: On the cost of concurrency in transactional memory. CoRR, abs/1103.1302 (2011)Google Scholar
- 20.Lee, J.: Compilation Techniques for Explicitly Parallel Programs. PhD thesis, Department of Computer Science, University of Illinois at Urbana-Champaign (1999)Google Scholar
- 21.McKenney, P.: Concurrent code and expensive instructions. Linux Weekly News (January 2011), http://lwn.net/Articles/423994/
- 22.McKenney, P.E.: Memory barriers: a hardware view for software hackers. Linux Technology Center, IBM Beaverton (June 2010)Google Scholar
- 24.Raynal, M.: Algorithms for Mutual Exclusion. MIT Press (1986)Google Scholar