Transactional memory: architectural support for lock-free data structures
ISCA '93 Proceedings of the 20th annual international symposium on computer architecture
Process structuring, synchronization, and recovery using atomic actions
Proceedings of an ACM conference on Language design for reliable software
The price of anarchy of finite congestion games
Proceedings of the thirty-seventh annual ACM symposium on Theory of computing
Advanced contention management for dynamic software transactional memory
Proceedings of the twenty-fourth annual ACM symposium on Principles of distributed computing
Toward a theory of transactional contention managers
Proceedings of the twenty-fourth annual ACM symposium on Principles of distributed computing
Selfish Routing and the Price of Anarchy
Selfish Routing and the Price of Anarchy
Transactional contention management as a non-clairvoyant scheduling problem
Proceedings of the twenty-fifth annual ACM symposium on Principles of distributed computing
A flexible framework for implementing software transactional memory
Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications
Bounds on Contention Management Algorithms
ISAAC '09 Proceedings of the 20th International Symposium on Algorithms and Computation
Exact price of anarchy for polynomial congestion games
STACS'06 Proceedings of the 23rd Annual conference on Theoretical Aspects of Computer Science
| Hi-index | 5.23 |
In a multicore transactional memory (TM) system, concurrent execution threads interact and interfere with each other through shared memory. The less interference a thread provokes the better for the system. However, as a programmer is primarily interested in optimizing her individual code's performance rather than the system's overall performance, she does not have a natural incentive to provoke as little interference as possible. Hence, a TM system must be designed compatible with good programming incentives (GPI), i.e., writing efficient code for the overall system should coincide with writing code that optimizes an individual thread's performance. We show that with most contention managers (CM) proposed in the literature so far, TM systems are not GPI compatible. We provide a generic framework for CMs that base their decisions on priorities and explain how to modify Timestamp-like CMs so as to feature GPI compatibility. In general, however, priority-based conflict resolution policies are prone to be exploited by selfish programmers. In contrast, a simple non-priority-based manager that resolves conflicts at random is GPI compatible.