Concurrent ML (CML) is a high-level message-passing language that supports the construction of first-class synchronous abstractions called events. This mechanism has proven quite effective over the years and has been incorporated in a number of other languages. While CML provides a concurrent programming model, its implementation has always been limited to uniprocessors. This limitation is exploited in the implementation of the synchronization protocol that underlies the event mechanism, but with the advent of cheap parallel processing on the desktop (and laptop), it is time for Parallel CML. Parallel implementations of CML-like primitives for Java and Haskell exist, but build on high-level synchronization constructs that are unlikely to perform well. This paper presents a novel, parallel implementation of CML that exploits a purpose-built optimistic concurrency protocol designed for both correctness and performance on shared-memory multiprocessors. This work extends and completes an earlier protocol that supported just a strict subset of CML with synchronization on input, but not output events. Our main contributions are a model-checked reference implementation of the protocol and two concrete implementations. This paper focuses on Manticore’s functional, continuation-based implementation but briefly discusses an independent, thread-based implementation written in C # and running on Microsoft’s stock, parallel runtime. Although very different in detail, both derive from the same design. Experimental evaluation of the Manticore implementation reveals good performance, dispite the extra overhead of multiprocessor synchronization.

Machine" [BB90], except that there are no "cooling" and "heating" transitions (the process sets of this semantics can be thought of as perpetually "hot" solutions). The concurrent evaluation relation extends "7\Gamma!" to finite sets of terms (i.e., processes) and adds additional rules for process creation, channel creation, and communication. We assume a set of process identifiers, and define the set of processes and process sets as: ß 2 ProcId process IDs p = hß; ei 2 Proc = (ProcId \Theta Exp) processes P 2 Fin(Proc) process sets We often write a process as hß; E[e]i, where the evaluation context serves the role of the program counter, marking the current state of evaluation. Definition4. A process set P is well-formed if for all hß; ei 2 P the following hold: -- FV(e) = ; (e is closed), and -- there is no e 0 6= e, such that hß; e 0 i 2 P. It is occasionally useful to view well-formed process sets as finite maps from ProcId to Exp. If P is a finite set of process state...

Recent attempts at incorporating concurrency into functional languages have identified synchronous communication via shared channels as a promising primitive. An additional useful feature found in many proposals is a nondeterministic choice operator. Similar in nature to the CSP alternative command, this operator allows different possible actions to be guarded by sends or receives. Choice is difficult to implement in a distributed environment because it requires offering many potential communications but closing only one. In this paper we present the first distributed, deadlock-free algorithm for choice. Keywords: Distributed protocols, channels, synchronous communication, choice operator, CSP alternative command. 1. Introduction In 1978, C.A.R. Hoare introduced a now-classic paradigm for parallel programming called communicating sequential processes, or CSP [12]. CSP presented a new approach to concurrent programming, and its legacy has continued to influence wellfounded pr...

Abstract. Concurrent ML (CML) is a high-level message-passing language that supports the construction of first-class synchronous abstractions called events. This mechanism has proven quite effective over the years and has been incorporated in a number of other languages. While CML provides a concurrent programming model, its implementation has always been limited to uniprocessors. This limitation is exploited in the implementation of the synchronization protocol that underlies the event mechanism, but with the advent of cheap parallel processing on the desktop (and laptop), it is time for Parallel CML. We are pursuing such an implementation as part of the Manticore project. In this paper, we describe a parallel implementation of Asymmetric CML (ACML), which is a subset of CML that does not support output guards. We describe an optimistic concurrency protocol for implementing CML synchronization. This protocol has been implemented as part of the Manticore system. 1

. The idea of making synchronous operations into first-class values is an important one for supporting abstraction and modularity in concurrent programs. This design principle has been used with great success in the concurrent language CML, but what are the limitations of this approach? This paper explains the rationale for first-class synchronous operations, and discusses their use in CML. It also presents some recent and fundamental results about the expressiveness of rendezvous primitives, which define the limitations of synchronous abstractions. 1 Introduction Abstraction is a key tool for managing complexity. The design of programming languages is one area where application of this idea has paid significant dividends. Languages have evolved from providing a fixed set of abstractions of the underlying hardware, such as arithmetic expressions and arrays, to providing support for programmer-defined abstractions, such as abstract data-types and higher-order procedures. By providing ...

In Concurrent ML, synchronization abstractions can be defined and passed as values, much like functions in ML. This mechanism admits a fairly powerful, modular style of concurrent programming, called higher-order concurrent programming. Unfortunately, it is not clear whether this style of programming can be practiced in languages such as Concurrent Haskell, that support only first-order message passing. Indeed, the implementation of synchronization abstractions in Concurrent ML relies on fairly low-level, languagespecific details. Fortunately, it turns out that synchronization abstractions can in fact be supported in a language that supports only first-order message passing. We implement such a library in this paper. This library makes it possible to practice Concurrent ML-style programming directly in Concurrent Haskell. We begin with a core implementation of synchronization abstractions in the π-calculus, that serves as a foundation for other concrete implementations. Then, we extend this implementation to encode all of Concurrent ML’s concurrency primitives (and more!) in Concurrent Haskell. Our implementation is surprisingly efficient, even without possible optimizations. Preliminary experiments suggest that our library can consistently outperform a standard implementation of Concurrent ML-style primitives. At the heart of our implementation is a new distributed synchronization protocol that we prove correct. Unlike several previous translations of synchronization abstractions in concurrent languages, we remain faithful to the standard semantics for Concurrent ML’s concurrency primitives; for example, we retain the symmetry of choose, that is required to express generalized selective communication. As a corollary, we establish that implementing generalized selective communication on distributed machines is no harder than implementing first-order message passing on such machines.

Parallelism is going mainstream. Many chip manufactures are turning to multicore processor designs rather than scalar-oriented frequency increases as a way to get performance in their desktop, enterprise, and mobile processors. This endeavor is not likely to succeed long term if mainstream applications cannot be parallelized to take advantage of tens and eventually hundreds of hardware threads. Multicore architectures will differ in significant ways from their multisocket predecessors. For example, the communication to compute bandwidth ratio is likely to be higher, which will positively impact performance. More generally, multicore architectures introduce several new dimensions of variability in both performance guarantees and architectural contracts, such as the memory model, that may not stabilize for several generations of product. Programs written in functional or (constraint-)logic programming languages, or even in other languages with a controlled use of side effects, can greatly simplify parallel programming. Such declarative programming allows for a deterministic semantics even when the underlying implementation might be highly