Technical Reports
HPL-2012-246
Click here for full text:
Why Locks Should Not Be Used In Generic Programming
Gottschlich, Justin E; Boehm, Hans-J.
HP Laboratories
HPL-2012-246
Keyword(s): locks; mutexes; generic programming; templates; transactional memory; deadlock
Abstract: Locks are the most widely used synchronization mechanism for threads. It is well-known that naive use of locks can easily lead to program failures through deadlock. Such deadlock is usually avoided through careful lock ordering. We argue that this approach is incompatible with several increasingly important programming practices that rely on libraries invoking ("calling-back") essentially unknown client code. Template-based generic programming in C++ is probably the most extreme in its use of call-backs, in that often almost every operator used in a generic function is potentially defined by client code. Template functions are essential to C++. Much of the standard library consists of template functions and classes. We expect the same to be increasingly true for libraries designed for concurrency that support synchronization. We argue that if locks are used for synchronization in such code we have no reliable methodology for avoiding deadlock; we need an alternate synchronization mechanism. We argue that transactional memory can extract us from this predicament. Unlike much of the debate surrounding transactional memory, we do not start with a focus on performance. We argue instead that transactional memory provides a desperately needed programmability improvement, which we have learned how to implement with sufficient performance to make it viable.
6 Pages
External Posting Date: December 21, 2012 [Fulltext]. Approved for External Publication
Internal Posting Date: December 21, 2012 [Fulltext]