Towards a Safer Interaction with Transactional Memory by Tracking Object Visibility
Yossi Lev, Jan-Willem Maessen · UR Research (University of Rochester) · 2005
Lately there has been an increasing interest in Transactional Memory (TM), a programming API that helps programmers writing scalable concurrent programs using sequential code. It is well known that writing concurrent programs using locks is a difficult task: coarse grained locking results in poor performance, and fine grained locking introduces the risk of deadlocking, and makes program's maintenance difficult. With TM, the programmer only specifies what is required to be executed atomically, without worrying about the synchronization required to achieve this task. There are suggested implementations for TM both in hardware (HTM) and software (STM). While HTM is much faster than STM, it also has more limitations than STM does, and therefore it is not likely that we will have a widely available TM that is implemented purely in hardware in the near future. While STM can compensate for most of the HTM limitations, it imposes a new difficulty on the programmer: STM does not allow concurrent access to an object by transactional and non-transactional code: that is, if an object is accessed using regular read and write operations while it is also being accessed by a transaction, the atomicity of the transaction involving this object might break. Requiring the programmer to keep track of which objects may be involved in transactions will only result in more error-prone concurrent programs. On the other hand, accessing all objects by only transactional code would be safe, but probably not practical as long as we do not have an efficient and robust pure HTM solution. We therefore introduce a new scheme that implicitly tracks object visibility: with our new scheme, objects that might be accessed by multiple threads are automatically guarded by transactions, and therefore are guaranteed not to be accessed by non-transactional code. Moreover, the scheme is transparent to the programmer, and can work with many different implementations of TM, including the lately suggested hybrid TM (HyTM) that uses STM only when HTM fails (or when HTM is not available).