Concurrent C

Three notations for concurrent programming are compared, namely CSP, Ada, and monitors. CSP is an experimental language for exploring structuring concepts in concurrent programming. Ada is a general-purpose language with concurrent programming facilities. Monitors are a construct for managing access by concurrent processes to shared resources. We start by comparing "lower-level" communication, synchronization, and nondeterminism in CSP and Ada and then examine "higher-level" module interface properties of Ada tasks and monitors.

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.

Multi-core processors are present in everyone's daily life. Consequently, concurrent programming has reemerged as a pressing concern for everyone interested in exploring all the potential computational power in these machines. But, the emergence of new concurrency models and programming languages also brings new challenges in terms of how one can deal with abnormal occurrences, much due to the heterogenous parallel control flow. Unexpectedly, sequential Exception Handling models remain as the most used tool for robustness, even in the most recent concurrent programming languages. Though, the appearance of more complex models, such as programming languages with implicit concurrency, might pose a challenge too big for these sequential mechanisms. In this article we will provide evidences why such models are not generally suited to deal with faults in programs with implicit concurrency and, in the light of more recent advances in concurrent Exception Handling, we will discuss the attributes of a model for addressing this problem.

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

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.

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

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.

Ada was designed with real-time programming in mind and therefore provides sophisticated concurrent programming facilities. This book describes these facilities with the aid of a variety of examples. In addition the non-concurrent features of Ada are carefully described in an appendix.

This paper describes a senior level course in concurrent programming using Ada. Unlike other similar courses in the subject area, it is not part of an operating systems course, nor is it tied to a particular hardware architecture. The course is software oriented and it discusses in depth a concurrent programming language, Ada, so that students are able to actually develop effective concurrent programs to solve problems in a wide range of applications. Ada is selected because of its popularity, superb portability, numerous hardware platforms, and rich concurrent constructs. Classical issues in concurrent programming are presented in the context of Ada. General issues in designing concurrent programming languages are elaborated using Ada, together with other concurrent programming languages such as CSP, Occam, and Linda. Finally, general principles of designing parallel programs are also discussed. Therefore, the course provides both the depth in a concurrent programming language for program development and the breadth in concurrent programming theory for insight. Using Ada throughout the course strengthens student's expertise in Ada and provides an useful reference point for understanding concurrent programming theory. The course is heavily based on handouts, examples, homework and programming assignments. A rich set of instructional materials are available from the author.

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.

Recently we have seen a renewed interest in programming languages that tame the complexity of state and concurrency through refined type systems with more fine-grained control over effects. In addition to simplifying reasoning and eliminating whole classes of bugs, statically tracking effects opens the door to advanced compiler optimizations. In this paper we present a relational model of a type-and-effect system for a higher-order, concurrent programming language. The model precisely captures the semantic invariants expressed by the effect annotations. We demonstrate that these invariants are strong enough to prove advanced program transformations, including automatic parallelization of expressions with suitably disjoint effects. The model also supports refinement proofs between abstract data type implementations with different internal data representations, including proofs that fine-grained concurrent algorithms refine their coarse-grained counterparts. This is the first model for such an expressive language that supports both effect-based optimizations and data abstraction. The logical relation is defined in Iris, a state-of-the-art higherorder concurrent separation logic. This greatly simplifies proving well-definedness of the logical relation and provides us with a powerful logic for reasoning in the model.

Smalltalk-80 provides only a minimal set of concurrency control mechanisms. The fork and newProcess messages can be used to indicate that two (or more) processes can run concurrently, and a Semaphore class is provided which can be used to achieve synchronization.These features are not enough, however, to simulate true concurrency. A process will not yield the processor until it can no longer continue. This makes it all too easy to unintentionally produce code which is dependent upon yielding the processor at some specific point.The Delay and Random classes were used to force processes to yield nondeterministically. This allowed a single processor, context switching environment to be simulated. The producer/consumer problem was used to exercise the concurrent mechanisms in this investigation.

The paper first identifies the concurrency requirements for a high-level concurrent programming language, and then discusses how the concurrency primitives proposed for the programming language Ada meet these requirements. This is followed by a description of an actual implementation of the Ada tasking constructs on a distributed multiprocessor computer system comprising a number of multiprocessor-shared memory stations linked by a serial communications network. A brief description of the system and the overheads involved when implementing the rendezvous mechanism on this architecture is presented, and also the implications of processing interrupts by mapping them into external entry calls to high-level service tasks are discussed

In the previous chapter we introduced the notion of a sequential process (agreeing that where no confusion would arise, the term process would be sufficient) in an informal way. Now we need to formalise this concept, and to provide some concrete examples of the representation of a process which will enable us to clarify the basic ideas behind systems of concurrent processes. We begin, however, by considering some of the issues concerning the nature of concurrent activity, and describing some of the notations which have been proposed whereby concurrency may be introduced into a program. Specification of Concurrent Activity There are a variety of ways of talking about concurrency, some of which have found their way into programming languages in various guises, and some of which are merely notational mechanisms for describing parallel activity. When discussing the ways in which parallel activity can be specified within a programming language or system, it is useful to consider two orthogonal features of any proposed method. The first is the specification of where in a program a separate process may be started, and where, if at all, it terminates. The specification of where a new process may begin and end provides some synchronisation points within the concurrent program. We assume that it is possible to specify that two processes may execute in parallel, and it is at that point that the two processes are assumed to be synchronised.

This collection of original research provides a comprehensive survey of developments at the leading edge of concurrent object-oriented programming. It documents progress—from general concepts to specific descriptions—in programming language design, semantic tools, systems, architectures, and applications. Chapters are written at a tutorial level and are accessible to a wide audience, including researchers, programmers, and technical managers. The problem of designing systems for concurrent programming has become an increasingly important area of research in computer science with a concomitant increase in the popularity of object-based programming. Because parallelism is a natural consequence of the use of objects, the development of systems for concurrent object-oriented programming is providing important software support for a new generation of concurrent computers.