Type-aware transactions for faster concurrent code

Herman, Nathaniel; Inala, Jeevana Priya; Huang, Yihe; Tsai, Lillian L.; Kohler, Eddie; Liskov, Barbara; Shrira, Liuba

doi:10.1145/2901318.2901348

Cited by 31 publications

(21 citation statements)

References 62 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Boosting was originally developed to enhance the concurrency provided by software transactional memory systems [10] by exploiting type-specific information. Other techniques that exploit type-specific properties to enhance concurrency in STMs include transactional predication [3] and software transactional objects [11].…”

Section: Related Workmentioning

confidence: 99%

Adding Concurrency to Smart Contracts

Dickerson

Gazzillo

Herlihy

et al. 2017

Proceedings of the ACM Symposium on Principles of Distributed Computing

119

View full text Add to dashboard Cite

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. This paper presents a novel way to permit miners and validators to execute smart contracts in parallel, based on techniques adapted from software transactional memory. Miners execute smart contracts speculatively in parallel, allowing non-conflicting contracts to proceed concurrently, and "discovering" a serializable concurrent schedule for a block's transactions, This schedule is captured and encoded as a deterministic fork-join program used by validators to re-execute the miner's parallel schedule deterministically but concurrently.Smart contract benchmarks run on a JVM with ScalaSTM show that a speedup of 1.33x can be obtained for miners and 1.69x for validators with just three concurrent threads.

show abstract

Section: Related Workmentioning

confidence: 99%

Adding Concurrency to Smart Contracts

Dickerson

Gazzillo

Herlihy

et al. 2017

Proceedings of the ACM Symposium on Principles of Distributed Computing

119

View full text Add to dashboard Cite

show abstract

“…They use plain Cicada tables as a memory pool; an index node is stored as a record, and pointers to index nodes and to indexed records use their record IDs. This scheme resembles concurrent index designs using software transactional memory [24,51].…”

Section: Indexingmentioning

confidence: 99%

Cicada

Lim

Kaminsky

Andersen

2017

Proceedings of the 2017 ACM International Conference on Management of Data

101

View full text Add to dashboard Cite

Multi-core in-memory databases promise high-speed online transaction processing. However, the performance of individual designs suffers when the workload characteristics miss their small sweet spot of a desired contention level, read-write ratio, record size, processing rate, and so forth. Cicada is a single-node multi-core in-memory transactional database with serializability. To provide high performance under diverse workloads, Cicada reduces overhead and contention at several levels of the system by leveraging optimistic and multi-version concurrency control schemes and multiple loosely synchronized clocks while mitigating their drawbacks. On the TPC-C and YCSB benchmarks, Cicada outperforms Silo, TicToc, FOEDUS, MOCC, twophase locking, Hekaton, and ERMIA in most scenarios, achieving up to 3X higher throughput than the next fastest design. It handles up to 2.07 M TPC-C transactions per second and 56.5 M YCSB transactions per second, and scans up to 356 M records per second on a single 28-core machine.

show abstract

“…Recent efforts on transactional data structures [18,30,41] allow programmers to write applications with transactions defined over particular objects (rather than arbitrary memory words) while guaranteeing atomicity and isolation. For example, STO [18] is a recent library that includes many transactional objects (e.g., arrays, maps, primitive types) that C++ developers can use in their transactions. STO relies on an op-timized variant of optimistic concurrency control (OCC) [19] to process transactions.…”

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

“…To better understand the benefits and limitations of DRP, we have built a modified version of STO [18]. Our experiments on a 64-core machine show that our modified STO achieves up to 3.6× higher throughput on the STAMP benchmark suite [8] than TL2 [11] and the existing STO [18]. Furthermore, our modifications improve the throughput of an implementation of the Silo multicore database [35] on STO by 6.6× at high contention; performance is comparable when contention is low.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Deferred Runtime Pipelining for contentious multicore software transactions

Angel

Shasha

2019

Proceedings of the Fourteenth EuroSys Conference 2019

View full text Add to dashboard Cite

DRP is a new concurrency control protocol for software transactional memory that achieves high throughput, even for skewed workloads that exhibit high contention. DRP builds on prior works that chop transactions into pieces to expose more concurrency opportunities, but unlike these works, DRP performs no static analyses and supports arbitrary workloads. DRP achieves a high degree of concurrency across most workloads and guarantees deadlock freedom, strict serializability, and opacity. We incorporate DRP into the software transactional objects library STO [18] and find that DRP improves STO's throughput on several STAMP benchmarks by up to 3.6×. Additionally, an in-memory multicore database implemented with our modified variant of STO outperforms databases that use OCC or transaction chopping for concurrency control. Specifically, DRP achieves 6.6× higher throughput than OCC when contention is high. Compared to transaction chopping, DRP achieves 3.3× higher throughput when contention is medium or low. Furthermore, our implementation achieves comparable performance to OCC and transaction chopping at other contention levels.

show abstract

Type-aware transactions for faster concurrent code

Cited by 31 publications

References 62 publications

Adding Concurrency to Smart Contracts

Adding Concurrency to Smart Contracts

Cicada

Deferred Runtime Pipelining for contentious multicore software transactions

Contact Info

Product

Resources

About