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.
PDF
download
878987797
028-85220240
