Demo Data from VLDB 2026 / reviewers in the wild / expert
Thomas D. Dickerson
dblp:43/8146
· DBLP profile ↗
4ranked-venue papers
4as first author
0since 2021 · last 2020
0000-0003-3564-6779ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 3 · 3 first-authorSoftware engineering, systems software and programming languages · 1 · 1 first-author
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
1 paper |
Concurrent programming · 100% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Distributed systems · 100% | |
| Databases, data mining, and information retrieval
1 paper |
Query processing and optimization · 100% |
Topics — the 7 heaviest of 7, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Query processing and optimization › query execution
concurrent query execution |
0.3 | 1 | 2017 | Adding Concurrency to Smart Contracts · PODC 2017 |
Concurrent programming
concurrent data structures |
0.3 | 1 | 2017 | Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017 |
Concurrent programming › transactional memory
software transactional memory |
0.3 | 1 | 2017 | Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017 |
Concurrent programming › concurrent data structures
transactional data structures |
0.3 | 1 | 2017 | Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017 |
Concurrent programming
transactional memory |
0.3 | 1 | 2017 | Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017 |
Distributed systems
blockchain |
0.3 | 1 | 2017 | Adding Concurrency to Smart Contracts · PODC 2017 |
Distributed systems › blockchain
smart contract |
0.3 | 1 | 2017 | Adding Concurrency to Smart Contracts · PODC 2017 |
Methods — techniques the papers use, named apart from their topics
concurrency control · 0.6transactional wrapper · 0.3conflict detection · 0.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2020 | Adding concurrency to smart contracts
Thomas D. Dickerson, Paul Gazzillo, Maurice Herlihy, Eric Koskinen |
Distributed Comput. | 1 |
| 2019 | Conflict Abstractions and Shadow Speculation for Optimistic Transactional Objects
Thomas D. Dickerson, Eric Koskinen, Paul Gazzillo, Maurice Herlihy |
APLAS | 1 |
| 2017 | Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data StructuresabstractMost STM systems are poorly equipped to support libraries of concurrent data structures. One reason is that they typically detect conflicts by tracking transactions' read sets and write sets, an approach that often leads to false conflicts. A second is that existing data structures and libraries often need to be rewritten from scratch to support transactional conflict detection and rollback. This brief announcement introduces Proust, a framework for the design and implementation of transactional data structures. Proust is designed to maximize reuse of existing well-engineered libraries by providing transactional "wrappers" to make existing thread-safe concurrent data structures transactional. Proustian objects are also integrated with an underlying STM system, allowing them to take advantage of well-engineered STM conflict detection mechanisms. Proust generalizes and unifies prior approaches such as boosting and predication. Thomas D. Dickerson, Paul Gazzillo, Maurice Herlihy, Eric Koskinen |
PODC | 1 |
| 2017 | Adding Concurrency to Smart ContractsabstractModern cryptocurrency systems, such as Ethereum, permit complex financial transactions through scripts called smart contracts. These smart contracts are executed many, many times, always without real concurrency. First, all smart contracts are serially executed by miners before appending them to the blockchain. Later, those contracts are serially re-executed by validators to verify that the smart contracts were executed correctly by miners. Serial execution limits system throughput and fails to exploit today's concurrent multicore and cluster architectures. Nevertheless, serial execution appears to be required: contracts share state, and contract programming languages have a serial semantics. Thomas D. Dickerson, Paul Gazzillo, Maurice Herlihy, Eric Koskinen |
PODC | 1 |