Transactional memory: architectural support for lock-free data structures
ISCA '93 Proceedings of the 20th annual international symposium on computer architecture
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
Brief announcement: selfishness in transactional memory
Proceedings of the twenty-first annual symposium on Parallelism in algorithms and architectures
Bounds on Contention Management Algorithms
ISAAC '09 Proceedings of the 20th International Symposium on Algorithms and Computation
Bounds on Contention Management Algorithms
ISAAC '09 Proceedings of the 20th International Symposium on Algorithms and Computation
ICALP'10 Proceedings of the 37th international colloquium conference on Automata, languages and programming: Part II
| Hi-index | 0.00 |
In a multicore transactional memory (TM) system, concurrent execution threads interact and interfere with each other through shared memory. The less interference a program 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 coincides with writing code that optimizes an individual program'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.