Demo Data from VLDB 2026 / reviewers in the wild / expert
Amir Levy
dblp:126/2049
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2014
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 2
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
2 papers |
Parallel and multicore computing · 79% Processor architecture and microarchitecture · 16% Distributed systems · 6% | |
| Software engineering, system software, and programming languages
1 paper |
Concurrent programming · 100% |
Topics — the 9 heaviest of 10, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Parallel and multicore computing › transactional memory
hardware transactional memory |
0.2 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Parallel and multicore computing › transactional memory
lock elision |
0.2 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Parallel and multicore computing
synchronization |
0.2 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Parallel and multicore computing
transactional memory |
0.2 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Concurrent programming › synchronization
lock elision |
0.2 | 1 | 2013 | Programming with hardware lock elision · PPoPP 2013 |
Concurrent programming
synchronization |
0.2 | 1 | 2013 | Programming with hardware lock elision · PPoPP 2013 |
Distributed systems
concurrency |
0.1 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Parallel and multicore computing › synchronization
critical section |
0.1 | 1 | 2014 | Software-improved hardware lock elision · PODC 2014 |
Concurrent programming › synchronization
locking |
0.0 | 1 | 2013 | Programming with hardware lock elision · PPoPP 2013 |
Methods — techniques the papers use, named apart from their topics
hardware lock elision · 0.3software extension mechanism · 0.2opacity · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2014 | Software-improved hardware lock elisionabstractWith hardware transactional memory (HTM) becoming available in mainstream processors, lock-based critical sections may now initiate a hardware transaction instead of taking the lock, enabling their concurrent execution unless a real data conflict occurs. However, just a few transactional aborts can cause the lock to be acquired non-transactionally resulting in the serialization of all the threads, severely degrading the amount of speedup obtained. In this paper we provide two software extension mechanisms that considerably improve the concurrency and speedup levels attained by lock based programs using HTM-based lock elision. The first sacrifices opacity to achieve higher levels of concurrency, and the second retains opacity while reaching slightly lower levels of concurrency. Yehuda Afek, Amir Levy, Adam Morrison 0001 |
PODC | 2 |
| 2013 | Programming with hardware lock elisionabstractWe present a simple yet effective technique for improving performance of lock-based code using the hardware lock elision (HLE) feature in Intel's upcoming Haswell processor. Yehuda Afek, Amir Levy, Adam Morrison 0001 |
PPoPP | 2 |