Composable asynchronous events

Ziarek, Lukasz; Sivaramakrishnan, KC; Jagannathan, Suresh

doi:10.1145/1993316.1993572

Cited by 8 publications

(9 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Full description of these combinators along with their formal semantics is available in Ziarek et al (2011). These combinators enable the extension of post-creation and post-consumption action of asynchronous events to create more complex events, and allow transformation between the synchronous and asynchronous events.…”

Section: Event Combinatorsmentioning

confidence: 99%

“…The details of the improvements along with the ACML code snippets is available is available as a case study in our earlier work (Ziarek et al, 2011). CML communication abstractions are utilized for inter-component interaction.…”

Section: Swervementioning

confidence: 99%

“…In the ML family of languages, Concurrent ML (CML) (Reppy, 2007), a synchronous message-passing dialect of ML, is a well-studied instantiation that provides event combinators, which can be used to construct sophisticated synchronous communication protocols. MULTIMLTON additionally provides support for ACML (Ziarek et al, 2011), an extension of CML that supports asynchronous events and the construction of heterogeneous protocols, which mix synchronous and asynchronous communication. Asynchrony can be used to mask communication latency by splitting the creation of a communication action from its consumption.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

MultiMLton: A multicore-aware runtime for standard ML

Sivaramakrishnan¹,

Ziarek²,

Jagannathan³

2014

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

MultiMLton is an extension of the MLton compiler and runtime system that targets scalable, multicore architectures. It provides specific support for ACML, a derivative of Concurrent ML that allows for the construction of composable asynchronous events. To effectively manage asynchrony, we require the runtime to efficiently handle potentially large numbers of lightweight, short-lived threads, many of which are created specifically to deal with the implicit concurrency introduced by asynchronous events. Scalability demands also dictate that the runtime minimize global coordination. MultiMLton therefore implements a split-heap memory manager that allows mutators and collectors running on different cores to operate mostly independently. More significantly, MultiMLton exploits the premise that there is a surfeit of available concurrency in ACML programs to realize a new collector design that completely eliminates the need for read barriers, a source of significant overhead in other managed runtimes. These two symbiotic features - a thread design specifically tailored to support asynchronous communication, and a memory manager that exploits lightweight concurrency to greatly reduce barrier overheads - are MultiMLton's key novelties. In this article, we describe the rationale, design, and implementation of these features, and provide experimental results over a range of parallel benchmarks and different multicore architectures including an 864 core Azul Vega 3, and a 48 core non-coherent Intel SCC (Single-Cloud Computer), that justify our design decisions.

show abstract

Section: Event Combinatorsmentioning

confidence: 99%

Section: Swervementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

MultiMLton: A multicore-aware runtime for standard ML

Sivaramakrishnan¹,

Ziarek²,

Jagannathan³

2014

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

show abstract

“…The context of our investigation is a programming model that is mostly functional (our benchmarks are written in the asynchronous extension [24] of Concurrent ML [18]), and that naturally supports large numbers of lightweight user-level threads. We have implemented our garbage collector for MultiMLton [17], a parallel extension to MLton [16], that targets scalable, many-core platforms.…”

Section: Motivationmentioning

confidence: 99%

Eliminating read barriers through procrastination and cleanliness

2012

Self Cite

View full text Add to dashboard Cite

Managed languages typically use read barriers to interpret forwarding pointers introduced to keep track of copied objects. For example, in a multicore environment with thread-local heaps and a global, shared heap, an object initially allocated on a local heap may be copied to a shared heap if it becomes the source of a store operation whose target location resides on the shared heap. As part of the copy operation, a forwarding pointer may be established in the original object to point to the copied object. This level of indirection avoids the need to update all of the references to the object that has been copied.In this paper, we consider the design of a managed runtime that eliminates read barriers. Our design is premised on the availability of a sufficient degree of concurrency to stall operations that would otherwise necessitate the copy. Stalled actions are deferred until the next local collection, avoiding exposing forwarding pointers to the mutator. In certain important cases, procrastination is unnecessary -lightweight runtime techniques can sometimes be used to allow objects to be eagerly copied when their set of incoming references is known, or when it can be determined that having multiple copies would not violate program semantics.We evaluate our techniques on 3 platforms: a 16-core AMD64 machine, a 48-core Intel SCC, and an 864-core Azul Vega 3. Experimental results over a range of parallel benchmarks indicate that our approach leads to notable performance gains (20 -32% on average) without incurring any additional complexity.

show abstract

“…This choice lets us retain a sequential programming model. Concurrent with our work, Ziarek et al developed a system for composable asynchronous events [40], building on the first-class event abstraction of Concurrent ML [28].…”

Section: Message-based Languagesmentioning

confidence: 99%

Ac

et al. 2011

View full text Add to dashboard Cite

This paper introduces AC, a set of language constructs for composable asynchronous IO in native languages such as C/C++. Unlike traditional synchronous IO interfaces, AC lets a thread issue multiple IO requests so that they can be serviced concurrently, and so that long-latency operations can be overlapped with computation. Unlike traditional asynchronous IO interfaces, AC retains a sequential style of programming without requiring code to use multiple threads, and without requiring code to be "stack-ripped" into chains of callbacks. AC provides an async statement to identify opportunities for IO operations to be issued concurrently, a do..finish block that waits until any enclosed async work is complete, and a cancel statement that requests cancellation of unfinished IO within an enclosing do..finish. We give an operational semantics for a core language. We describe and evaluate implementations that are integrated with message passing on the Barrelfish research OS, and integrated with asynchronous file and network IO on Microsoft Windows. We show that AC offers comparable performance to existing C/C++ interfaces for asynchronous IO, while providing a simpler programming model.

show abstract

Composable asynchronous events

Cited by 8 publications

References 20 publications

MultiMLton: A multicore-aware runtime for standard ML

MultiMLton: A multicore-aware runtime for standard ML

Eliminating read barriers through procrastination and cleanliness

Ac

Contact Info

Product

Resources

About