Type-and-effect systems are a natural approach for statically reasoning about a program’s execution. They have been used to track a variety of computational effects, for example memory manipulation, exceptions, and locking. However, each type-and-effect system is typically implemented as its own monolithic type system that hard-codes a particular syntax of effects along with particular rules to track and control those effects. We present a generic type-and-effect system, which is parameterized by the syntax of effects to track and by two functions that together specify the effect discipline to be statically enforced. We describe how a standard form of type soundness is ensured by requiring these two functions to obey a few natural monotonicity requirements. We demonstrate that several effect systems from the literature can be viewed as instantiations of our generic type system. Finally, we describe the implementation of our type-and-effect system and mechanically checked type soundness proof in the Twelf proof assistant.

Asynchronous systems programs are usually written in an event-driven style which is tailored for performance rather than analyzability. Such programs have non-sequential control ow and make heavy use of heap data structures to store and retrieve state related to pending operations. As a result, existing tools that analyze sequential programs are ine ective in analyzing asynchronous systems components. We describe clarity, a programming language that enables analyzable design of asynchronous components. clarity has three novel features: (1) Nonblocking function calls that allow event-driven code to be written in a sequential style. If a blocking statement is encountered during the execution of such a call, the call returns and the remainder of the operation is automatically queued for later execution. (2) Coords, a set of high-level coordination primitives, encapsulate common interactions between asynchronous components and make high-level coordination protocols explicit. (3) Linearity annotations delegate coord protocol obligations to exactly one thread at each asynchronous function call, transforming a concurrent analysis problem into a sequential one. We demonstrate how these language features enable both a more intuitive expression of program logic and more e ective program analysis most checking is done using simple sequential analysis. We describe our experience in developing, testing, and analyzing a network device driver using clarity. 1.

Writing correct and efficient concurrent programs still remains a challenge. Explicit concurrency is difficult, error prone, and creates code which is hard to maintain and debug. This type of concurrency also treats modular program design and concurrency as separate goals, where modularity often suffers. To solve these problems, we are designing a new language that we call Panini. In this paper, we focus on Panini's asynchronous, typed events which reconcile the modularity goal promoted by the implicit invocation design style with the concurrency goal of exposing potential concurrency between the execution of subjects and observers. Since modularity is improved and concurrency is implicit in Panini, programs are easier to reason about and maintain. Furthermore, races and deadlocks are avoided entirely, yielding programs with a guaranteed sequential semantics. To evaluate our language design and implementation we show several examples of its usage as well as an empirical study of program performance. We found that not only is developing and understanding Panini programs significantly easier compared to standard concurrent object-oriented programs, but performance of Panini programs is comparable to their equivalent hand-tuned versions written using Java's fork-join framework.

Abstract. An error was discovered by M.F. Atig in the coverability graph based decision procedure we defined in [2]. We thank him for bringing the error to our knowledge. We refer the interested reader to [1] for updated results about the verification of liveness properties for asynchronous programs. We show below at Fig. 1 and 2 that the coverability graph does not provide enough precision to determine the existence of fair infinite runs. main () { b:=false; while(NONDET) { post h1(); loc1 post h2(); loc2 h1() { b:=true; init loop exit h1 h2 d F 1 d F 2 bF dT d 2 T 1 bT h2() { if (b==true) post h2(); dloc Figure 1. An asynchronous program and its PN counterpart which has a fair infinite run init loop i exit d F 1 (d T 1) i−1 (d T 2) ω. 1 2 PIERRE GANTY, RUPAK MAJUMDAR, AND ANDREY RYBALCHENKO

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 anasync 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.

Despite widespread interest in multicore computing, concurrency models in mainstream languages often lead to subtle, error-prone code. Observationally Cooperative Multithreading (OCM) is a new approach to shared-memory parallelism. Programmers write code using the well-understood cooperative (i.e., nonpreemptive) multithreading model for uniprocessors. OCM then allows threads to run in parallel, so long as results remain consistent with the cooperative model. Programmers benefit because they can reason largely sequentially. Remaining interthread interactions are far less chaotic than in other models, permitting easier reasoning and debugging. Programmers can also defer the choice of concurrency-control mechanism (e.g., locks or transactions) until after they have written their programs, at which point they can compare concurrency-control strategies and choose the one that offers the best performance. Implementers and researchers also benefit from the agnostic nature of OCM— it provides a level of abstraction to investigate, compare, and combine a variety of interesting concurrency-control techniques.