Handling exceptions in programs with hidden concurrency: new challenges for old solutions

Practical exception handling and resolution in concurrent programs

Stephen J. Hartley Oxford University Press, New York, 1998, 260 pp. ISBN 0-19-511315-2, $45.00 Concurrent Programming is a thorough treatment of Java multi-threaded programming for both a stand-alone and distributed environment. Designed mostly for students in concurrent or parallel programming classes, the text is also an excellent reference for the practicing professional developing multi-threaded programs or applets. Hartley first provides a complete explanation of the features of Java necessary to write concurrent programs, including topics such as exception handling, interfaces, and packages. He then gives the reader a solid background to write multi-threaded programs and also presents the problems introduced when writing concurrent programs—namely race conditions, mutual exclusion, and deadlock. Hartley also provides several software solutions that do not require the use of common process and thread mechanisms. Once the groundwork is laid for writing concurrent programs, Hartley then takes a different approach than most Java references. Rather than presenting how Java handles mutual exclusion with the synchronized keyword (although it is covered later), he first looks at semaphore-based solutions to classic concurrent problems such as bounded-buffer, readers-writers, and the dining philosophers. Hartley also uses the same approach to develop Java classes for monitors and message passing. This unique approach to introducing concurrency allows the readers to both understand how Java threads are synchronized and how the basic synchronization mechanism can be used to construct more abstract tools such as semaphores. If there is a shortcoming with the text it is with the lack of sufficient coverage of remote method invocation (RMI), although there is a section covering RMI. This is quite understandable as RMI is a fairly recent phenomenon with the Java community. Also, the classes that Hartley provides could easily implement RMI rather than sockets to handle communication. The strengths of the book include its ease in reading, several examples at the end of chapters, a package similar to Xtango that provides algorithm animation, and a supportive web site by the author (see www.mcs.drexel.edu/~shartley/ConcProgJava/index.html ) including compressed source code. As Java becomes more dominant on the server side of multi-tier applications, writing thread-safe concurrent applications becomes even more important. Concurrent Programming is a strong step towards teaching students and professionals such skills. Greg Gagne, Westminster College of Salt Lake City Salt Lake City, Utah

A problem which confronts the developers of concurrent logic programming (CLP) systems concerns the design of the programming environment, particularly the provision of debugging tools. Debugging tools are useful for many activities besides identifying bugs: they can help in program testing and demonstration, in software experiments, and in teaching the language semantics. For CLP languages the questions of what debugging tools should be provided, and of how they should be used, are still open. Although the languages are closely related to other logic programming and concurrent programming languages, they are sufficiently different that new debugging techniques are required. This paper describes a primarily channel-oriented debugging methodology and a set of debugging tools that we have developed in the light of our experience in using and teaching the CLP language Parlog. With these tools a programmer can test a program by observing communication on channels, opening up a process to examine the activity on internal channels and, if necessary, to check in detail the execution steps of a process. Almost all of the ideas, which are equally applicable to other CLP languages, have been implemented in two commercial Parlog systems. As well as fulfilling the needs of existing users of CLP languages, we believe that the tools emphasise the attractions of CLP as a concurrent programming paradigm, since they are made possible by the unique attributes of CLP.

Verification of Concurrent Assembly Programs with a Petri Net Based Safety Policy

Exception handling mechanisms have been introduced into programming languages in an effort to help deal with runtime irregularities. These mechanisms aim to improve code reliability by providing constructs for sectioning code into exception scopes (e.g. Java try blocks) and exception handlers (e.g. Java catch blocks). Whilst exception handling mechanisms have been the focus of much research over the past years, empirical studies have only focused on characterising exception handling code of Java and C# programs. There exists little empirical evidence on how exception handling mechanisms are used to develop software with other programming languages. Moreover, to date there exists no empirical study which has examined the structure of exception scopes across software projects. We address these shortcomings by examining the commonalities and differences of both exception scopes and handlers implemented with a wider range of languages. To this end, we analysed 50 software projects, containing code developed in C++, JavaScript, PHP, Java and C#. More than 9 million lines of code and over 20,000 exceptional code blocks were analysed. Our findings revealed significant differences in the frequency, structure and length of exception scopes and exception handlers across languages. This finding suggests that certain exception handling mechanisms are less explored by programmers using certain programming languages. However, regardless of language, exception handlers remained simplistic and in general only ever one handler was associated with each scope. Finally, our analysis confirms the existing belief that developers often pay little attention to developing exception scoping and handling behaviour.

Teaching concurrent and parallel programming by patterns: An interactive ICT approach

Background Software developers are increasingly required to write concurrent code. However, most developers find concurrent programming difficult. To better help developers, it is imperative to understand their interest and difficulties in terms of concurrency topics they encounter often when writing concurrent code.Aims In this work, we conduct a large-scale study on the textual content of the entirety of Stack Overflow to understand the interests and difficulties of concurrency developers.Method First, we develop a set of concurrency tags to extract concurrency questions that developers ask. Second, we use latent Dirichlet allocation (LDA) topic modeling and an open card sort to manually determine the topics of these questions. Third, we construct a topic hierarchy by repeated grouping of similar topics into categories and lower level categories into higher level categories. Fourth, we investigate the coincidence of our concurrency topics with findings of previous work. Fifth, we measure the popularity and difficulty of our concurrency topics and analyze their correlation. Finally, we discuss the implications of our findings.Results A few findings of our study are the following. (1) Developers ask questions about a broad spectrum of concurrency topics ranging from multithreading to parallel computing, mobile concurrency to web concurrency and memory consistency to run-time speedup. (2) These questions can be grouped into a hierarchy with eight major categories: concurrency models, programming paradigms, correctness, debugging, basic concepts, persistence, performance and GUI. (3) Developers ask more about correctness of their concurrent programs than performance. (4) Concurrency questions about thread safety and database management systems are among the most popular and the most difficult, respectively. (5) Difficulty and popularity of concurrency topics are negatively correlated.Conclusions The results of our study can not only help concurrency developers but also concurrency educators and researchers to better decide where to focus their efforts, by trading off one concurrency topic against another.

The reality of multi-core hardware has made concurrent programs pervasive. Unfortunately, writing correct concurrent programs is difficult. Addressing this challenge requires advances in multiple directions, including concurrency bug detection, concurrent program testing, concurrent programming model design, etc. Designing effective techniques in all these directions will significantly benefit from a deep understanding of real world concurrency bug characteristics. This paper provides the first (to the best of our knowledge) comprehensive real world concurrency bug characteristic study. Specifically, we have carefully examined concurrency bug patterns, manifestation, and fix strategies of 105 randomly selected real world concurrency bugs from 4 representative server and client open-source applications (MySQL, Apache, Mozilla and OpenOffice). Our study reveals several interesting findings and provides useful guidance for concurrency bug detection, testing, and concurrent programming language design. Some of our findings are as follows: (1) Around one third of the examined non-deadlock concurrency bugs are caused by violation to programmers' order intentions, which may not be easily expressed via synchronization primitives like locks and transactional memories; (2) Around 34% of the examined non-deadlock concurrency bugs involve multiple variables, which are not well addressed by existing bug detection tools; (3) About 92% of the examined concurrency bugs canbe reliably triggered by enforcing certain orders among no more than 4 memory accesses. This indicates that testing concurrent programs can target at exploring possible orders among every small groups of memory accesses, instead of among all memory accesses; (4) About 73% of the examinednon-deadlock concurrency bugs were not fixed by simply adding or changing locks, and many of the fixes were not correct at the first try, indicating the difficulty of reasoning concurrent execution by programmers.

The recent turn towards multicore processing architectures has made concurrency an important part of mainstream software development. As a result, an increasing number of developers have to learn to write concurrent programs, a task that is known to be hard even for the expert. Language designers are therefore working on languages that promise to make concurrent programming "easier". However, the claim that a new language is more usable than another cannot be supported by purely theoretical considerations, but calls for empirical studies. In this paper, we present the design of a study to compare concurrent programming languages with respect to comprehending and debugging existing programs and writing correct new programs. A critical challenge for such a study is avoiding the bias that might be introduced during the training phase and when interpreting participants' solutions. We address these issues by the use of self-study material and an evaluation scheme that exposes any subjective decisions of the corrector, or eliminates them altogether. We apply our design to a comparison of two object-oriented languages for concurrency, multithreaded Java and SCOOP (Simple Concurrent Object-Oriented Programming), in an academic setting. We obtain results in favor of SCOOP even though the study participants had previous training in writing multithreaded Java programs.

A comparative study of exception handling mechanisms for building dependable object-oriented software

Some legacy programming languages, e.g., C, do not provide adequate support for exception handling. As a result, users of these legacy programming languages often implement exception handling by applying an idiom. An idiomatic style of implementation has a number of drawbacks: applying idioms can be fault prone and requires significant effort. Modern programming languages provide support for structured exception handling (SEH) that makes idioms largely obsolete. Additionally, aspect-oriented programming (AOP) is believed to further reduce the effort of implementing exception handling. This paper investigates the gains that can be achieved by reengineering the idiomatic exception handling of a legacy C component to these modern techniques. First, we will reengineer a C component such that its exception handling idioms are almost completely replaced by SEH constructs. Second, we will show that the use of AOP for exception handling can be beneficial, even though the benefits are limited by inconsistencies in the legacy implementation.

High-performance programs and systems require concurrency to take full advantage of available hardware. However, the available concurrent programming models force a difficult choice, between simple models such as mutual exclusion that produce little to no concurrency, or complex models such as Read-Copy Update that can scale to all available resources. Simple concurrent programming models enforce atomicity and causality, and this enforcement limits concurrency. Scalable concurrent programming models expose the weakly ordered hardware memory model, requiring careful and explicit enforcement of causality to preserve correctness, as demonstrated in this dissertation through the manual construction of a scalable hash-table item-move algorithm. Recent research on "relativistic programming" aims to standardize the programming model of Read-Copy Update, but thus far these efforts have lacked a generalized memory ordering model, requiring data-structure-specific reasoning to preserve causality. I propose a new memory ordering model, "relativistic causal ordering", which combines the scalabilty of relativistic programming and Read-Copy Update with the simplicity of reader atomicity and automatic enforcement of causality. Programs written for the relativistic model translate to scalable concurrent programs for weakly-ordered hardware via a mechanical process of inserting barrier operations according to well-defined rules. To demonstrate the relativistic causal ordering model, I walk through the straightforward construction of a novel concurrent hash-table resize algorithm, including the translation of this algorithm from the relativistic model to a hardware memory model, and show through benchmarks that the resulting algorithm scales far better than those based on mutual exclusion.

Saraswat recently introduced the framework of concurrent constraint programming [14]. The essence of the framework is that computations consist of concurrent agents interacting by communicating constraints. Several concurrent constraint programming languages have been defined. They differ in the kinds of constraints that can be used as well as the kinds of operations on constraints which are available. In this paper we introduce a very simple concurrent constraint language we call Lucy, designed to closely mimic the actor model of computation. Agents can communicate only by the posting of constraints upon bags (un-ordered collections possibly with duplicate elements). This very impoverished concurrent constraint language is a syntactic subset of Janus, a concurrent constraint language which closely resembles concurrent logic programming languages such as Guarded Horn Clauses [21], Strand [5], Parlog [2] and Flat Concurrent Prolog [13]. By identifying the subset of Janus which is an actor language, we elucidate the relationship between actors and concurrent logic programming (and its generalization as concurrent constraint programming). Lucy is best not thought of as a unification of logic and constraint programming with actor and object-oriented programming, but as the missing link between these programming language genera.

simpA: An agent-oriented approach for programming concurrent applications on top of Java

Design verification has grown to dominate the cost of electronic system design; however, designs continue to be released with latent bugs. A verification test suite developed for a sequential program is not adequate for a concurrent program. A major problem with design verification of concurrent systems is the lack of good coverage metrics. Coverage metrics are heuristic measures of the exhaustiveness of a test suite. High coverage, in general, implies fewer bugs. SystemC is the most popular concurrent system level modeling language used for designing SoCs in the industry. We propose to attack the verification quality problem for concurrent SystemC programs by developing novel mutation testing based coverage metrics. Mutation testing has successfully been applied in software testing and RTL designs. In this paper, we develop a comprehensive set of mutation operators for concurrency constructs in SystemC. Our approach is also unique in that we define a novel concurrent coverage metric considering multiple execution schedules that a concurrent program can generate. This metric allows us to adequately measure the coverage for concurrent programs. We performed experiments with various designs including a large industrial design and obtained favorable results on multiple applications.