Asynchronous Exceptions Research Articles

Dependency safety for Java – Implementing and testing failboxes

• We present a testing framework tailor-made for testing how multi-threaded Java programs handle asynchronous exceptions. • We explain how failboxes can be used in practice to produce multi-threaded Java programs that guarantee dependency safety. • We present a number of possible implementations of the failbox concept, in order of their robustness. • For each implementation, we discuss its weaknesses, and demonstrate these via tests performed with our testing framework. • Our final implementation is robust w.r.t. asynchronous exceptions. It is the first one that provides this guarantee. Exception mechanisms help to ensure that a program satisfies the important robustness criterion of dependency safety: if an operation fails in an execution sequence, any code depending on the successful completion of this operation should also fail in a controlled way. However, the exception handling mechanisms available in languages like Java do not provide a structured way to achieve dependency safety. The language extension failbox provides dependency safety in a compositional manner. Asynchronous exceptions occurring inside the failbox code are a serious challenge in achieving dependency safety. In this article we present a Java implementation which deals with this challenge by developing failboxes incrementally, through four increasingly robust iterations. For each incremental implementation step we analyze the vulnerabilities and argue the remedies in the next implementation. We also present a testing approach to investigate whether the vulnerabilities are realistic and the remedies proposed are effective. This testing approach enables us to generate asynchronous exceptions in a controlled manner for concurrent programs and the tests are repeatable in that they give the same results for runs that may differ in scheduling, even on different platforms.

Satin

Computational grids have an enormous potential to provide compute power. However, this power remains largely unexploited today for most applications, except trivially parallel programs. Developing parallel grid applications simply is too difficult. Grids introduce several problems not encountered before, mainly due to the highly heterogeneous and dynamic computing and networking environment. Furthermore, failures occur frequently, and resources may be claimed by higher-priority jobs at any time. In this article, we solve these problems for an important class of applications: divide-and-conquer. We introduce a system called Satin that simplifies the development of parallel grid applications by providing a rich high-level programming model that completely hides communication. All grid issues are transparently handled in the runtime system, not by the programmer. Satin's programming model is based on Java, features spawn-sync primitives and shared objects, and uses asynchronous exceptions and an abort mechanism to support speculative parallelism. To allow an efficient implementation, Satin consistently exploits the idea that grids are hierarchically structured. Dynamic load-balancing is done with a novel cluster-aware scheduling algorithm that hides the long wide-area latencies by overlapping them with useful local work. Satin's shared object model lets the application define the consistency model it needs. If an application needs only loose consistency, it does not have to pay high performance penalties for wide-area communication and synchronization. We demonstrate how grid problems such as resource changes and failures can be handled transparently and efficiently. Finally, we show that adaptivity is important in grids. Satin can increase performance considerably by adding and removing compute resources automatically, based on the application's requirements and the utilization of the machines and networks in the grid. Using an extensive evaluation on real grids with up to 960 cores, we demonstrate that it is possible to provide a simple high-level programming model for divide-and-conquer applications, while achieving excellent performance on grids. At the same time, we show that the divide-and-conquer model scales better on large systems than the master-worker approach, since it has no single central bottleneck.

Exceptions in Concurrent Eiffel.

We describe the problem of asynchronous exceptions in Eiffel’s Simple Concurrent Object-Oriented Programming (SCOOP). We discuss a range of possible solutions to further enable dependable computing in concurrent Eiffel. We propose a mechanism to handle aynchronous exceptions via a limited developer choice, including the notion of a failed or dead object, and necessarily introduce a small number of new exceptions. We additionally describe a number of mechanisms that were discarded as unsuitable.

Preface: Volume 41, Issue 2

This issue results from the 4th International Workshop on High-Level Concurrent Languages (HLCL 2000), held as a satellite event to PLI 2000 in Montreal, Canada, on September 20, 2000.The workshop is intended to bring together active researchers involved in the design, development, foundations, and applications of high-level concurrent (and distributed) programming languages and models. The theme is that such programming models should be simple, practical, high-level, and well-founded. These qualities allow rigorous language specifications and support both formal and informal reasoning about programs. For concurrent and distributed systems, research on programming models has driven the design of several recent programming languages including Erlang, CML, Facile, and Haskell, as well as languages explicitly designed for concurrency or distribution such as HACL, JoCaml, Obliq, Oz, (Nomadic) Pict, and TyCO. Although the motivations behind the design of these languages are diverse (ranging from the development of graphical user interfaces and multi-agent systems to constraint, real-time, and distributed programming), suitable foundations have turned out to be quite similar in style and technique, often based on variants of well-known calculi for mobile processes.Programme14.20-14.30Open14.30-15.20An Overview of Functional Nets. Invited Talk: Martin Odersky15.20-16.00Asynchronous Exceptions in Haskell. Simon Marlow, Simon Peyton-Jones, Andrew MoranBreak16.30-17.20A distributed programming language for building security infrastructures. Invited Talk: Trevor Jim17.20-18.00A Distributed Calculus with Local Areas of Communication. Tom Chothia and Ian Stark.CloseSubmissions were reviewed by the program committee; a preliminary proceedings containing the above was produced for the workshop. Of these, the paper by Chothia and Stark has been revised for inclusion in this issue.We are very grateful to Uwe Nestmann and Benjamin Pierce (HLCL Organizing Committee), Amy Felty (PLI Workshop Chair) and Mike Mislove (Managing Editor of ENTCS).Program CommitteeCedric Fournet (Microsoft Research UK)Alan Jeffrey (DePaul University, USA)Trevor Jim (ATT Labs, USA)Naoki Kobayashi (University of Tokyo, Japan)Uwe Nestmann (Aalborg University, Denmark)John Reppy (Bell Labs, USA) (Co-chair)Aleta Riccardi (Bell Labs, USA)Peter Sewell (University of Cambridge, UK) (Co-chair)Gert Smolka (Universität des Saarlandes, Germany)

Asynchronous exceptions in Haskell

Asynchronous exceptions, such as timeouts are important for robust, modular programs, but are extremely difficult to program with — so much so that most programming languages either heavily restrict them or ban them altogether. We extend our earlier work, in which we added synchronous exceptions to Haskell, to support asynchronous exceptions too. Our design introduces scoped combinators for blocking and unblocking asynchronous interrupts, along with a somewhat surprising semantics for operations that can suspend. Uniquely, we also give a formal semantics for our system.

Optimization and precise exceptions in dynamic compilation

Maintaining precise exceptions is an important aspect of achieving full compatibility with a legacy architecture. While asynchronous exceptions can be deferred to an appropriate boundary in the code, synchronous exceptions must be taken when they occur. This introduces uncertainty into liveness analysis since processor state that is otherwise dead may be exposed when an exception handler is invoked. Previous systems either had to sacrifice full compatibility to achieve more freedom to perform optimization, use less aggressive optimization or rely on hardware support.In this work, we demonstrate how aggressive optimization can be used in conjunction with dynamic compilation without the need for specialized hardware. The approach is based on maintaining enough state to recompute the processor state when an unpredicted event such as a synchronous exception may make otherwise dead processor state visible. The transformations necessary to preserve precise exception capability can be performed in linear time.

Effective use of abort in programming mode changes

Mode changes are a crucial characteristic of a number of real-time systems. Ada does not easily deal with these events and hence it has been argued that language changes are required; in particular the introduction (or strictly speaking the re-introduction) of asynchronous exceptions. In this paper we present an idiom for programming mode changes. Moreover we argue that this structure can be implemented efficiently.

Asynchronous transfer of control in Ada 9X

The Taft proposal is described in detail. It involves introducing a new "and" clause into the select statement thereby providing a means of programming asynchronous transfer of control without the use of the abort facility. An evaluation of the proposal considers some of its limitations, the major one of which is the possibility of deadlock if a group of tasks use the facility to affect each other. Ways of removing this difficulty are considered. The model is then compared with the alternative of introducing asynchronous exceptions. Finally a unified model is presented that combines the advantages of the Taft proposal and asynchronous exceptions.

Programming atomic actions in Ada

Atomic actions are often seen as an important structuring aid in the design and construction of fault tolerant programs. In this paper we consider whether recoverable atomic action can be implemented in Ada using the language's communication and synchronisation mechanisms. Whilst simple atomic actions can be programmed in Ada, recoverable actions cannot because the language does not have an asynchronous exception facility.

Ramifications of re-introducing asynchronous exceptions to the Ada language

Re-introduction of asynchronous exceptions into the Ada language has been suggested as a means to solve certain problems in intertask communication. The author argues that such re-introduction would provide inconsistent and nondeterministic semantics, disallow several important classes of optimization, cause considerable distributed overhead, complicate program proof and verification efforts, prove error-prone to use, and offer little new functionality. Further discussions of alternate solutions to the requirements which motivated asynchronous exceptions are encouraged.

Exceptions and interrupts in CSP

Preemptive commands to handle asynchronous exceptions and interrupts are proposed for CSP. The semantics are defined within Hoare's process model for CSP [4]. The model is then extended for process execution resulting in operational semantics that accommodate the necessary expression of process priority.