Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Thomas D. Dickerson

dblp:43/8146 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Query processing and optimization › query execution
concurrent query execution
0.312017
Adding Concurrency to Smart Contracts · PODC 2017
Concurrent programming
concurrent data structures
0.312017
Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017
Concurrent programming › transactional memory
software transactional memory
0.312017
Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017
Concurrent programming › concurrent data structures
transactional data structures
0.312017
Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017
Concurrent programming
transactional memory
0.312017
Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures · PODC 2017
Distributed systems
blockchain
0.312017
Adding Concurrency to Smart Contracts · PODC 2017
Distributed systems › blockchain
smart contract
0.312017
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
YearPublicationVenuePosition
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
APLAS1
2017 Brief Announcement: Proust: A Design Space for Highly-Concurrent Transactional Data Structures
abstract
Most 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
PODC1
2017 Adding Concurrency to Smart Contracts
abstract
Modern 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
PODC1