Advanced contention management for dynamic software transactional memory

By William N. Scherer, Michael Lee Scott. ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, 2005

469 citations recorded by the source corpus.

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

Concurrent programming without locks (2007, methodology): “Other schemes may work better [ Scherer III and Scott 2005 ] and, since DSTM is obstruction-free, they would be expected to influence its performance more than OSTM’s.”
NV-Heaps: making persistent objects fast and safe with next-generation, non-volatile memories (2011, background): “The contention management scheme [52] backs off and retries in case of conflict.”
LogTM: log-based transactional memory (2006, background): “The decision can be made quickly, but myopically, by hardware, or slowly, but carefully, by a software contention manager [26].”
Transactional Memory, 2nd edition (2010, background): “No policy has been found which performs universally best in all settings, though Polka has often worked well [280], as have hybrids that switch from a simple passive algorithm to a more complex one if contention is seen, or if transactions become long-running [93].”
Hybrid transactional memory (2006, methodology): “In some cases, it may make sense to retry the transaction in hardware, perhaps after a short delay to reduce contention and improve the chances of committing in hardware; such delays may be effected by simple backoff techniques [2], or by more sophisticated contention control techniques [10, 28].”
Transactional memory (2010, methodology): “Several studies have been conducted on contention managers and policies, e.g., [40, 41, 42, 43, 44].”