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 det...
| Main Authors: | , |
|---|---|
| Other Authors: | |
| Format: | Article |
| Language: | English |
| Published: |
Springer Science+Business Media
2016
|
| Online Access: | http://hdl.handle.net/1721.1/103289 |
| _version_ | 1826189314393899008 |
|---|---|
| author | Pankratius, Victor Adl-Tabatabai, Ali-Reza |
| author2 | Massachusetts Institute of Technology. Computer Science and Artificial Intelligence Laboratory |
| author_facet | Massachusetts Institute of Technology. Computer Science and Artificial Intelligence Laboratory Pankratius, Victor Adl-Tabatabai, Ali-Reza |
| author_sort | Pankratius, Victor |
| collection | MIT |
| description | 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. |
| first_indexed | 2024-09-23T08:12:49Z |
| format | Article |
| id | mit-1721.1/103289 |
| institution | Massachusetts Institute of Technology |
| language | English |
| last_indexed | 2024-09-23T08:12:49Z |
| publishDate | 2016 |
| publisher | Springer Science+Business Media |
| record_format | dspace |
| spelling | mit-1721.1/1032892022-09-23T11:41:27Z Software Engineering with Transactional Memory Versus Locks in Practice Pankratius, Victor Adl-Tabatabai, Ali-Reza Massachusetts Institute of Technology. Computer Science and Artificial Intelligence Laboratory Pankratius, Victor 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. Karlsruhe Institute of Technology (Excellence Initiative) 2016-06-23T15:01:17Z 2016-06-23T15:01:17Z 2013-03 2016-05-23T12:13:59Z Article http://purl.org/eprint/type/JournalArticle 1432-4350 1433-0490 http://hdl.handle.net/1721.1/103289 Pankratius, Victor, and Ali-Reza Adl-Tabatabai. “Software Engineering with Transactional Memory Versus Locks in Practice.” Theory Comput Syst 55, no. 3 (March 3, 2013): 555–590. en http://dx.doi.org/10.1007/s00224-013-9452-5 Theory of Computing Systems Article is made available in accordance with the publisher's policy and may be subject to US copyright law. Please refer to the publisher's site for terms of use. Springer Science+Business Media New York application/pdf Springer Science+Business Media Springer US |
| spellingShingle | Pankratius, Victor Adl-Tabatabai, Ali-Reza Software Engineering with Transactional Memory Versus Locks in Practice |
| title | Software Engineering with Transactional Memory Versus Locks in Practice |
| title_full | Software Engineering with Transactional Memory Versus Locks in Practice |
| title_fullStr | Software Engineering with Transactional Memory Versus Locks in Practice |
| title_full_unstemmed | Software Engineering with Transactional Memory Versus Locks in Practice |
| title_short | Software Engineering with Transactional Memory Versus Locks in Practice |
| title_sort | software engineering with transactional memory versus locks in practice |
| url | http://hdl.handle.net/1721.1/103289 |
| work_keys_str_mv | AT pankratiusvictor softwareengineeringwithtransactionalmemoryversuslocksinpractice AT adltabatabaialireza softwareengineeringwithtransactionalmemoryversuslocksinpractice |