Reagents

Turon, Aaron

doi:10.1145/2254064.2254084

Cited by 6 publications

(3 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Actors [Agha 1986] are a message passing-based programming model for loosely-coupled distributed and concurrent event-driven applications. Software Transactional Memory [Shavit and Touitou 1995] schedules arbitrary, composable [Ni et al 2007] read/write transactions, Reagents [Turon 2012] are abstractions for implementing data structures that can be safely composed into concurrent algorithms. Both use łoptimistic lockingž which is ill-named since transactions are executed speculatively without locking accessed variables, but are only committed if no race conditions occurred until they complete and otherwise aborted.…”

Section: Discussionmentioning

confidence: 99%

Thread-safe reactive programming

Drechsler

Mogk

Salvaneschi

et al. 2018

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

The execution of an application written in a reactive language involves transfer of data and control flow between imperative and reactive abstractions at well-defined points. In a multi-threaded environment, multiple such interactions may execute concurrently, potentially causing data races and event ordering ambiguities. Existing RP languages either disable multi-threading or handle it at the cost of reducing expressiveness or weakening consistency. This paper proposes a model for thread-safe reactive programming (RP) that ensures abort-free strict serializability under concurrency while sacrificing neither expressiveness nor consistency. We also propose an architecture for integrating a corresponding scheduler into the RP language runtime, such that thread-safety is provided łout-of-the-boxž to the applications.We show the feasibility of our proposal by providing and evaluating a ready-to-use implementation integrated into the REScala programming language. The scheduling algorithm is formally proven correct. A thorough empirical evaluation shows that reactive applications build on top of it scale with multiple threads, while the scheduler incurs acceptable performance overhead in a single-threaded configuration. The scalability enabled by our scheduler is roughly on-par with that of hand-crafted application-specific locking and better than the scalability enabled by a scheduler using an off-the-shelf software transactional memory library. 1 We chose REScala, because its API is designed to support different backend runtimes.Thread-Safe Reactive Programming 107:3 with that of hand-crafted application-specific locking, and better while also providing stronger guarantees than a scheduler using an off-the-shelf Software Transactional Memory library. ğ2 introduces RP concepts from the user perspective, ğ6 positions our approach with respect to related work, and ğ7 concludes the paper and discusses areas of future work. REACTIVE PROGRAMMING IN RESCALAWe introduce (single-threaded) RP from the developer's perspective by implementing an example application in REScala. Our design is inspired by the dining philosophers [Hoare 1985], with philosophers sharing forks around a table. We later introduce concurrency and discuss its effects through multiple threads concurrently executing updates for different philosophers. For flexibility in later examples and benchmarks, the table's SIZE (number of philosophers and forks) is parametric. The User PerspectiveWe introduce Events, Signals, conversions between them and their imperative interactions.Signals. Philosophers are modelled as Vars of type Phil, initially in state Thinking. 1 cases Phil = { Thinking, Eating } 2 val phils = for (j <− 1 until SIZE) yield Var[Phil](Thinking)A REScala Var is a kind of mutable variable. Like ordinary variables, the value of a Var can be read (through now, e.g., phils(1).now reads the current value of the philosopher with index 1) and overwritten (through set(...), e.g., phils(1).set(Eating)). Unlike ordinary variables, changes of Vars are autom...

show abstract

Section: Discussionmentioning

confidence: 99%

Thread-safe reactive programming

Drechsler

Mogk

Salvaneschi

et al. 2018

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…52,54 Our compiler-driven approach can be potentially used to automate other advanced synchronization mechanisms as well, for example, fine-grained locking, 15 flat combining, 28 among others. [55][56][57][58][59] Herlihy and Moss 60 first proposed transactional memory as a hardware architecture, the materialization of which includes Intel TSX 61 and AMD ASF. 62 Our auto-generated code can be converted to using hardware-level transactional operations if needed.…”

Section: Related Workmentioning

confidence: 99%

“…Single‐word compare and swap (CAS) has been widely used as a primitive for implementing lock‐free or wait‐free synchronizations 52,54 . Our compiler‐driven approach can be potentially used to automate other advanced synchronization mechanisms as well, for example, fine‐grained locking, 15 flat combining, 28 among others 55‐59 …”

Section: Related Workmentioning

confidence: 99%

Compiler‐driven approach for automating nonblocking synchronization in concurrent data abstractions

Zhang,

Yi,

Peterson

et al. 2023

Concurrency and Computation

View full text Add to dashboard Cite

SummaryThis paper presents an extended version of our previous work on using compiler technology to automatically convert sequential C++ data abstractions, for example, queues, stacks, maps, and trees, to concurrent lock‐free implementations. A key difference between our work and existing research in software transactional memory (STM) is that our compiler‐based approach automatically selects the best state‐of‐the‐practice nonblocking synchronization method for the underlying sequential implementation of the data structure. The extended material includes a broader collection of the state‐of‐the‐practice lock‐free synchronization techniques, additional formal correctness proofs of the overall integration of the different synchronizations in our system, and a more comprehensive experimental study of the integrated techniques. We evaluate our compiler‐generated nonblocking data structures both by using a collection of micro‐benchmarks, including the Synchrobench suite, and by using a multi‐threaded application Dedup from PARSEC. Our automatically synchronized code attains performance competitive to that of concurrent data structures manually‐written by experts and much better performance than heavier‐weight support by STM.

show abstract

Automating Non-Blocking Synchronization In Concurrent Data Abstractions

Zhang

Dechev

2019

2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE)

View full text Add to dashboard Cite

Reagents

Cited by 6 publications

References 35 publications

Thread-safe reactive programming

Thread-safe reactive programming

Compiler‐driven approach for automating nonblocking synchronization in concurrent data abstractions

Automating Non-Blocking Synchronization In Concurrent Data Abstractions

Contact Info

Product

Resources

About