Recent years have seen significant advances in dynamic software updating (DSU) systems, which allow programs to be patched on the fly. Most DSU systems employ automatic safety checks to avoid applying a patch if doing so may lead to incorrect behavior. This paper presents what we believe is the first comprehensive empirical evaluation of the two most significant DSU safety checks: activeness safety (AS), which disallows patches that modify functions on the stack, and con-freeness safety (CFS), which allows modifications to active functions, but only when doing so will be type safe. To measure the checks ’ effectiveness, we tested them against three years of updates to OpenSSH and vsftpd. We performed this testing using a novel DSU testing methodology that systematically applies updates throughout the execution of a test suite. After testing updates to both applications in this way, we tracked how often the safety checks allow updates and which updates result in test failures. We found that updating without safety checks produced many failures, and that both AS and CFS dramatically reduced, but did not fully eliminate, these failures. CFS yielded more failures than AS, but AS was more restrictive than CFS, disallowing far more successful updates. Our results suggest that neither AS nor CFS is likely suitable for generalpurpose DSU on its own. Indeed, we found that selecting update points manually could avoid all failures while still permitting sufficient updates. Our results present a challenge and important insights for future work: to discover safe and sufficient update points fully automatically.

Orc was originally presented as a process calculus. It has now evolved into a full programming language, which we describe in this paper. The language has the structure and feel of a functional programming language, yet it handles many non-functional aspects effectively, including spawning of concurrent threads, time-outs and mutable state. We first describe the original concurrency combinators of the process calculus. Next we describe a small functional programming language that forms the core language. Then we show how the concurrency combinators of the process calculus and the functional core language are integrated seamlessly. The resulting language and its supporting libraries have proven very effective in describing typical concurrent computations; we demonstrate how several practical concurrent programming problems are easily solved in Orc.

The report will show how process-oriented discrete event simulation can be performed in the programming language Erlang. A small introduction to simulation and Erlang is given. The model used for discrete event simulation in Erlang and mechanisms for interaction in-between simulation processes are described. The author also illustrates how an extension to distributed simulation can be made. Descriptive examples and larger applications are presented. In the last passage of the report function calls for the simulator are given. ii Contents 1 Introduction 1 2 What is Erlang? 3 2.1 Erlang : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 2.2 Modules, Functions and Clauses : : : : : : : : : : : : : : : : : : : : : : 4 2.3 Data Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2.4 Pattern Matching : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2.5 Concurrency : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : ...

Transactional memory is being advanced as an alternative to traditional lock-based synchronization for concurrent programming. Transactional memory simplifies the programming model and maximizes concurrency. At the same time, transactions can suffer from interference that causes them to often abort, from heavy overheads for memory accesses, and from expressiveness limitations (e.g., for I/O operations). In this paper we propose an adaptive locking technique that dynamically observes whether a critical section would be best executed transactionally or while holding a mutex lock. The critical new elements of our approach include the adaptivity logic and cost-benefit analysis, a low-overhead implementation of statistics collection and adaptive locking in a full C compiler, and an exposition of the effects on the programming model. In experiments with both micro- and macro-benchmarks we found adaptive locks to consistently match or outperform the better of the two component mechanisms (mutexes or transactions). Compared to either mechanism alone, adaptive locks often provide 3-to-10x speedups. Additionally, adaptive locks simplify the programming model by reducing the need for fine-grained locking: with adaptive locks, the programmer can specify coarse-grained locking annotations and often achieve fine-grained locking performance due to the transactional memory mechanisms.

Quicksort [5] remains one of the most studied algorithms in computer science. It is important not only as a practical sorting method, but also as a splendid teaching aid for introducing recursion and systematic algorithm development. The algorithm has been studied extensively; so, it is natural to assume that everything that needs to be said about it has already been said. Yet, in attempting to code it using a recent programming language of our design, we discovered that its structure is more clearly expressed as a concurrent program that manipulates a shared mutable store, without any locking or explicit synchronization. In this paper, we describe the essential aspects of our programming language Orc [8], show a number of examples that combine its features in various forms, and then develop a concise description of Quicksort. We hope to highlight the importance of including concurrency, recursion and mutability within a single theory.

The Manticore project is an effort to design and implement a new functional language for parallel programming. Unlike many earlier parallel languages, Manticore is a heterogeneous language that supports parallelism at multiple levels. Specifically, the Manticore language combines Concurrent ML-style explicit concurrency with fine-grain, implicitly threaded, parallel constructs. These lectures will introduce the Manticore language and explore a variety of programs written to take advantage of heterogeneous parallelism. At the explicit-concurrency level, Manticore supports the creation distinct threads of control and the coordination of threads through first-class synchronous-message passing. Message-passing synchronization, in contrast to shared-memory synchronization, fits naturally with the functional-programming paradigm. At the implicit-parallelism level, Manticore supports a diverse collection of parallel constructs for different granularities of work. Many of these constructs are inspired by common functional-programming idioms. In addition to describing the basic mechanisms, we will present a number of useful programming techniques that are enabled by these mechanisms. Finally, we will briefly discuss some of the implementation techniques used to execute Manticore programs on commodity multicore computers. 1

Abstract. Dynamic software updating (DSU) systems allow running programs to be patched on-the-fly to add features or fix bugs. While dynamic updates can be tricky to write, techniques for establishing their correctness have received little attention. In this paper, we present the first methodology for automatically verifying the correctness of dynamic updates. Programmers express the desired properties of an updated execution using client-oriented specifications (CO-specs), which can describe a wide range of client-visible behaviors. We verify CO-specs automatically by using off-the-shelf tools to analyze a merged program, which is a combination of the old and new versions of a program. We formalize the merging transformation and prove it correct. We have implemented a program merger for C, and applied it to updates for the Redis key-value store and several synthetic programs. Using Thor, a verification tool, we could verify many of the synthetic programs; using Otter, a symbolic executor, we could analyze every program, often in less than a minute. Both tools were able to detect faulty patches and incurred only a factor-of-four slowdown, on average, compared to single version programs. 1