EDBT 2026 Demo / reviewers in the wild / expert
Bhandari Aditya
dblp:84/605
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2007
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1
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.
| Software engineering, system software, and programming languages
2 papers |
Concurrent programming · 62% Operating systems · 38% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Parallel and multicore computing · 100% |
Topics — the 7 heaviest of 8, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Operating systems › resource management › process management
CPU scheduling |
0.1 | 1 | 2007 | TxLinux: using and managing hardware transactional memory in an operating system · SOSP 2007 |
Concurrent programming › transactional memory
hardware transactional memory |
0.1 | 1 | 2007 | TxLinux: using and managing hardware transactional memory in an operating system · SOSP 2007 |
Operating systems › kernel › kernel design
kernel synchronization |
0.1 | 1 | 2007 | MetaTM//TxLinux: transactional memory for an operating system · ISCA 2007 |
Concurrent programming
synchronization |
0.1 | 1 | 2007 | TxLinux: using and managing hardware transactional memory in an operating system · SOSP 2007 |
Concurrent programming
transactional memory |
0.1 | 1 | 2007 | TxLinux: using and managing hardware transactional memory in an operating system · SOSP 2007 |
Parallel and multicore computing › transactional memory
hardware transactional memory |
0.1 | 1 | 2007 | MetaTM//TxLinux: transactional memory for an operating system · ISCA 2007 |
Parallel and multicore computing
transactional memory |
0.1 | 1 | 2007 | MetaTM//TxLinux: transactional memory for an operating system · ISCA 2007 |
Methods — techniques the papers use, named apart from their topics
cooperative transactional spinlocks · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2007 | MetaTM//TxLinux: transactional memory for an operating systemabstractThis paper quantifies the effect of architectural design decisions onthe performance of TxLinux. TxLinux is a Linux kernel modifiedto use transactions in place of locking primitives in several key subsystems.We run TxLinux on MetaTM, which is a new hardwaretransaction memory (HTM) model.MetaTM contains features that enable efficient and correct interrupthandling for an x86-like architecture. Live stack overwrites can corrupt non-transactional stack memory and requires a smallchange to the transaction register checkpoint hardware to ensurecorrect operation of the operating system. We also propose stack based early release to reduce spurious conflicts on stack memorybetween kernel code and interrupt handlers.We use MetaTM to examine the performance sensitivity of individualarchitectural features. For TxLinux we find that Polka and SizeMatters are effective contention management policies, someform of backoff on transaction contention is vital for performance,and stalling on a transaction conflict reduces transaction restartrates, but does not improve performance. Transaction write setsare small, and performance is insensitive to transaction abort costsbut sensitive to commit costs. Hany E. Ramadan, Christopher J. Rossbach, Donald E. Porter, Owen S. Hofmann, Bhandari Aditya, Emmett Witchel |
ISCA | 5 |
| 2007 | TxLinux: using and managing hardware transactional memory in an operating systemabstractTxLinux is a variant of Linux that is the first operating system to use hardware transactional memory (HTM) as a synchronization primitive, and the first to manage HTM in the scheduler. This paper describes and measures TxLinux and discusses two innovations in detail: cooperation between locks and transactions, and theintegration of transactions with the OS scheduler. Mixing locks and transactions requires a new primitive, cooperative transactional spinlocks (cxspinlocks) that allow locks and transactions to protect the same data while maintaining the advantages of both synchronization primitives. Cxspinlocks allow the system to attemptexecution of critical regions with transactions and automatically roll back to use locking if the region performs I/O. Integrating the scheduler with HTM eliminates priority inversion. On a series ofreal-world benchmarks TxLinux has similar performance to Linux, exposing concurrency with as many as 32 concurrent threads on 32 CPUs in the same critical region. Christopher J. Rossbach, Owen S. Hofmann, Donald E. Porter, Hany E. Ramadan, Bhandari Aditya, Emmett Witchel |
SOSP | 5 |