Theory of Computing Systems

, Volume 55, Issue 3, pp 555–590 | Cite as

Software Engineering with Transactional Memory Versus Locks in Practice



Transactional Memory (TM) promises to simplify parallel programming by replacing locks with atomic transactions. Despite much recent progress in TM research, there is very little experience using TM to develop realistic parallel programs from scratch. In this article, we present the results of a detailed case study comparing teams of programmers developing a parallel program from scratch using transactional memory and locks. We analyze and quantify in a realistic environment the development time, programming progress, code metrics, programming patterns, and ease of code understanding for six teams who each wrote a parallel desktop search engine over a fifteen week period. Three randomly chosen teams used Intel’s Software Transactional Memory compiler and Pthreads, while the other teams used just Pthreads. Our analysis is exploratory: Given the same requirements, how far did each team get? The TM teams were among the first to have a prototype parallel search engine. Compared to the locks teams, the TM teams spent less than half the time debugging segmentation faults, but had more problems tuning performance and implementing queries. Code inspections with industry experts revealed that TM code was easier to understand than locks code, because the locks teams used many locks (up to thousands) to improve performance. Learning from each team’s individual success and failure story, this article provides valuable lessons for improving TM.


Parallel programming Transactional memory Language design Human factors Synchronization Programming techniques 


  1. 1.
    Adl-Tabatabai, A.-R., Shpeisman, T. (eds.): Draft Specification of Transactional Language Constructs for C++ (v.1.0) (2009) Google Scholar
  2. 2.
    Adl-Tabatabai, A.-R., et al.: Compiler and runtime support for efficient software transactional memory. In: Proc. ACM PLDI’06, pp. 26–37 (2006) Google Scholar
  3. 3.
    Ansari, M., et al.: Lee-TM: a non-trivial benchmark suite for transactional memory. In: Algorithms and Architectures for Parallel Processing, pp. 196–207 (2008) CrossRefGoogle Scholar
  4. 4.
    Bacon, D., et al.: The “double-checked locking is broken” declaration. (2011)
  5. 5.
    Baek, W., et al.: The OpenTM transactional application programming interface. In: Proc. ACM PACT’07 (2007) Google Scholar
  6. 6.
    Baeza-Yates, R., Ribeiro-Neto, B.: Modern Information Retrieval. Addison-Wesley, Reading (1999) Google Scholar
  7. 7.
    Bienia, C., et al.: The PARSEC benchmark suite: characterization and architectural implications. In: Proc. ACM PACT’08, pp. 72–81 (2008) Google Scholar
  8. 8.
    Butenhof, D.R.: Programming with POSIX Threads. Addison-Wesley, Reading (1997) Google Scholar
  9. 9.
    Cascaval, C., et al.: Software transactional memory: why is it only a research toy? Commun. ACM 51(11), 40–46 (2008) CrossRefGoogle Scholar
  10. 10.
    Dalessandro, L., et al.: Transactional mutex locks. In: EuroPar (2010) Google Scholar
  11. 11.
    Damron, P., et al.: Hybrid transactional memory. In: Proc. ACM ASPLOS-XII, pp. 336–346 (2006) CrossRefGoogle Scholar
  12. 12.
    Gray, J., Reuter, A.: Transaction Processing: Concepts and Techniques. Morgan Kaufmann, San Mateo (1993) MATHGoogle Scholar
  13. 13.
    Guerraoui, R., et al.: STMBench7: a benchmark for software transactional memory. Oper. Syst. Rev. 41(3), 315–324 (2007) CrossRefMathSciNetGoogle Scholar
  14. 14.
    Harris, T., et al.: Composable memory transactions. In: Proc. ACM PPoPP’05, pp. 48–60 (2005) Google Scholar
  15. 15.
    Heinz, S., et al.: Burst tries: a fast, efficient data structure for string keys. ACM Trans. Inf. Syst. 20(2), 192–223 (2002) CrossRefGoogle Scholar
  16. 16.
    Herlihy, M., Moss, J.E.B.: Transactional memory: architectural support for lock-free data structures. In: Proc. ACM ISCA’93, pp. 289–300 (1993) Google Scholar
  17. 17.
    Intel: Intel C++ STM compiler prototype edition 2.0. language extensions and user’s guide (2008) Google Scholar
  18. 18.
    Kumar, S., et al.: Hybrid transactional memory. In: Proc. ACM PPoPP’06, pp. 209–220 (2006) Google Scholar
  19. 19.
    Lester, N., et al.: Efficient online index construction for text databases. ACM Trans. Database Syst. 33(3), 1–33 (2008) CrossRefGoogle Scholar
  20. 20.
    Minh, C.C., et al.: STAMP: Stanford transactional applications for multi-processing. In: Proc. IISWC (2008) Google Scholar
  21. 21.
    Moore, K., et al.: LogTM: log-based transactional memory. In: Proc. HPCA’06, pp. 254–265 (2006) Google Scholar
  22. 22.
    Ni, Y., et al.: Design and implementation of transactional constructs for C/C++. In: Proc. ACM OOPSLA (2008) Google Scholar
  23. 23.
    Pankratius, V.: Automated usability evaluation of parallel programming constructs (NIER track). In: Proc. ACM ICSE (2012) Google Scholar
  24. 24.
    Pankratius, V., Adl-Tabatabai, A.-R.: A study of transactional memory vs. locks in practice. In: Proc. ACM SPAA (2011) Google Scholar
  25. 25.
    Pankratius, V., et al.: Does transactional memory keep its promises? Results from an empirical study. Technical report, 2009-12, University of Karlsruhe, Germany (2009) Google Scholar
  26. 26.
    Pankratius, V., et al.: OpenMPspy: leveraging quality assurance for parallel software. In: Proc. Euro-Par (2012) Google Scholar
  27. 27.
    Ringenburg, M.F., Grossman, D.: AtomCaml: first-class atomicity via rollback. In: Proc. ACM ICFP (2005) Google Scholar
  28. 28.
    Rossbach, C.J., et al.: Txlinux: using and managing hardware transactional memory in an operating system. In: Proc. ACM SOSP’07, pp. 87–102 (2007) Google Scholar
  29. 29.
    Rossbach, C.J., et al.: Is transactional programming actually easier. In: Proc. ACM PPoPP (2010) Google Scholar
  30. 30.
    Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empir. Softw. Eng. 14(2), 131–164 (2009) CrossRefGoogle Scholar
  31. 31.
    Saha, B., et al.: McRT-STM: a high performance software transactional memory system for a multi-core runtime. In: Proc. ACM PPoPP’06, pp. 187–197 (2006) Google Scholar
  32. 32.
    Scott, M., et al.: Delaunay triangulation with transactions and barriers. In: Proc. IEEE IISWC (2007) Google Scholar
  33. 33.
    Shavit, N., Touitou, D.: Software transactional memory. Distrib. Comput. 10(2), 99–116 (1997) CrossRefGoogle Scholar
  34. 34.
    Standard Performance Evaluation Corporation: SPEC OpenMP benchmark suite. (2009)
  35. 35.
  36. 36.
    Watson, I., et al.: A study of a transactional parallel routing algorithm. In: Proc. ACM PACT’07, pp. 388–398 (2007) Google Scholar
  37. 37.
    Welc, A., et al.: Transparently reconciling transactions with locking for Java synchronization. In: Proc. ECOOP (2006) Google Scholar
  38. 38.
    Woo, S.C., et al.: The SPLASH-2 programs: characterization and methodological considerations. In: ACM ISCA (1995) Google Scholar
  39. 39.
    Yin, R.K.: Case Study Research: Design and Methods, 3rd edn. Sage, Thousand Oaks (2002) Google Scholar
  40. 40.
    Zannier, C., et al.: On the success of empirical studies in the international conference on software engineering. In: Proc. ACM ICSE’06, pp. 341–350 (2006) Google Scholar
  41. 41.
    Zyulkyarov, F., et al.: Atomic quake: using transactional memory in an interactive multiplayer game server. In: Proc. ACM PPoPP’09, pp. 25–34 (2009) Google Scholar

Copyright information

© Springer Science+Business Media New York 2013

Authors and Affiliations

  1. 1.Massachusetts Institute of TechnologyCambridgeUSA
  2. 2.Programming Systems LabIntel CorporationSanta ClaraUSA

Personalised recommendations