Software partitioning of hardware transactions

Xiang, Lingxiang; Scott, Michael L.

doi:10.1145/2688500.2688506

Cited by 21 publications

(3 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Os dados também mostram que nesse caso valeria a pena averiguar a possibilidade de dividir uma transação dominante em outras, com o objetivo de aliviar o uso dos recursos de hardware. De fato, abordagens recentes de memória transacional híbrida começaram a explorar essa direção [Xiang andScott 2015, Matveev andShavit 2015].…”

Section: Análise Dos Resultadosunclassified

Reavaliando o Conjunto de Aplicações STAMP em um Novo Hardware Transacional

Carvalho¹,

Murari²,

Baldassin³

2015

Anais Do XVI Simpósio Em Sistemas Computacionais De Alto Desempenho (SSCAD 2015)

View full text Add to dashboard Cite

Nos últimos quatro anos, IBM® e Intel® disponibilizaram processadores com suporte para memória transacional. A maioria dos trabalhos avaliaram esses processadores usando as aplicações STAMP e consideraram apenas as causas de cancelamentos das aplicações como um todo. Neste trabalho, apresenta-se uma análise por transação do STAMP e contrasta-se diferentes métricas de desempenho para determinar os motivos fundamentais pelo baixo desempenho do HaswellTM em algumas aplicações. Em resumo, os resultados mostram que uma transação domina o tempo de execução e tem poucas efetivações porque excede a capacidade restrita do processador, ou gera muitos conﬂitos quando executada em hardware.

show abstract

Section: Análise Dos Resultadosunclassified

Reavaliando o Conjunto de Aplicações STAMP em um Novo Hardware Transacional

Carvalho¹,

Murari²,

Baldassin³

2015

Anais Do XVI Simpósio Em Sistemas Computacionais De Alto Desempenho (SSCAD 2015)

View full text Add to dashboard Cite

show abstract

“…On the one hand, STMs are typically slower than locks, due to their instrumentation overhead. On the other hand, HTMs are not mature enough and cannot yet fully replace locking [59]. Flat combining [35] is a technique for optimizing coarse-grained locks (e.g., the global lock of a queue).…”

Section: Related Work Lock Algorithmsmentioning

confidence: 99%

Locking Made Easy

Antić

Chatzopoulos

Guerraoui

et al. 2016

Proceedings of the 17th International Middleware Conference

View full text Add to dashboard Cite

A priori, locking seems easy: To protect shared data from concurrent accesses, it is sufficient to lock before accessing the data and unlock after. Nevertheless, making locking efficient requires finetuning (a) the granularity of locks and (b) the locking strategy for each lock and possibly each workload. As a result, locking can become very complicated to design and debug.We present GLS, a middleware that makes lock-based programming simple and effective. GLS offers the classic lock-unlock interface of locks. However, in contrast to classic lock libraries, GLS does not require any effort from the programmer for allocating and initializing locks, nor for selecting the appropriate locking strategy. With GLS, all these intricacies of locking are hidden from the programmer. GLS is based on GLK, a generic lock algorithm that dynamically adapts to the contention level on the lock object. GLK is able to deliver the best performance among simple spinlocks, scalable queue-based locks, and blocking locks. Furthermore, GLS offers several debugging options for easily detecting various lockrelated issues, such as deadlocks.We evaluate GLS and GLK on two modern hardware platforms, using several software systems (i.e., HamsterDB, Kyoto Cabinet, Memcached, MySQL, SQLite) and show how GLK improves their performance by 23% on average, compared to their default locking strategies. We illustrate the simplicity of using GLS and its debugging facilities by rewriting the synchronization code for Memcached and detecting two potential correctness issues. CCS Concepts•Computing methodologies → Shared memory algorithms; Concurrent algorithms; •Computer systems organization → Multicore architectures; Keywords Locking; Adaptive Locking; Locking Middleware; Locking Runtime; Synchronization; Multi-cores; Performance * Work done while the author was at EPFL. Currently at Google. † Author names appear in alphabetical order.Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

show abstract

“…Although HTM already exists in commercial processors [30], it is not yet ubiquitous. Additionally, naively implementing CDSs with HTM results in non-scalable implementations (e.g., accessing the whole list within a transaction) [50].…”

Section: Introductionmentioning

confidence: 99%

Optimistic concurrency with OPTIK

Guerraoui

Trigonakis

2016

Proceedings of the 21st ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming

View full text Add to dashboard Cite

We introduce OPTIK, a new practical design pattern for designing and implementing fast and scalable concurrent data structures. OPTIK relies on the commonly-used technique of version numbers for detecting conflicting concurrent operations. We show how to implement the OPTIK pattern using the novel concept of OPTIK locks. These locks enable the use of version numbers for implementing very efficient optimistic concurrent data structures. Existing state-of-the-art lock-based data structures acquire the lock and then check for conflicts. In contrast, with OPTIK locks, we merge the lock acquisition with the detection of conflicting concurrency in a single atomic step, similarly to lock-free algorithms. We illustrate the power of our OPTIK pattern and its implementation by introducing four new algorithms and by optimizing four state-of-the-art algorithms for linked lists, skip lists, hash tables, and queues. Our results show that concurrent data structures built using OPTIK are more scalable than the state of the art.

show abstract

Software partitioning of hardware transactions

Cited by 21 publications

References 20 publications

Reavaliando o Conjunto de Aplicações STAMP em um Novo Hardware Transacional

Reavaliando o Conjunto de Aplicações STAMP em um Novo Hardware Transacional

Locking Made Easy

Optimistic concurrency with OPTIK

Contact Info

Product

Resources

About