Concurrent programming is notoriously di#cult. Current abstractions are intricate and make it hard to design computer systems that are reliable and scalable. We argue that these problems can be addressed by moving to a declarative style of concurrency control in which programmers directly indicate the safety properties that they require.

Much has been learned in the last decade about concurrent programming..This patmr identifies the major concepts of concurrent programming and describes some of the more importam language notations for writing concurrent programs. The roles of processes, communication, and synchronization are discussed. Language notations for expressing

We survey parallel programming models and languages using 6 criteria [:] should be easy to program, have a software development methodology, be architecture-independent, be easy to understand, guranatee performance, and provide info about the cost of programs. ... We consider programming models in 6 categories, depending on the level of abstraction they provide.

It is often desirable, for reasons of clarity, portability, and efficiency, to write parallel programs in which the number of processes is independent of the number of available processors. Several modern operating systems support more than one process in an address space, but the overhead of creating and synchronizing kernel processes can be high. Many runtime environments implement lightweight processes (threads) in user space, but this approach usually results in second-class status for threads, making it difficult or impossible to perform scheduling operations at appropriate times (e.g. when the current thread blocks in the kernel). In addition, a lack of common assumptions may also make it difficult for parallel programs or library routines that use dissimilar thread packages to communicate with each other, or to synchronize access to shared data. We describe a set of kernel mechanisms and conventions designed to accord first-class status to user-level threads, allowing them to be used in any reasonable way that traditional kernel-provided processes can be used, while leaving the details of their implementation to userlevel code. The key features of our approach are (1) shared memory for asynchronous communication between the kernel and the user, (2) software interrupts for events that might require action on the part of a user-level scheduler, and (3) a scheduler interface convention that facilitates interactions in user space between dissimilar kinds of threads. We have incorporated these mechanisms in the Psyche parallel operating system, and have used them to implement several different kinds of user-level threads. We argue for our approach in terms of both flexibility and performance.

SR is a language for programming distributed systems ranging from operating systems to application programs. On the basis of our experience with the initial version, the language has evolved consider-ably. In this paper we describe the current version of SR and give an overview of its implementation. The main language constructs are still resources and operations. Resources encapsulate processes and variables that they share; operations provide the primary mechanism for process interaction. One way in which SR has changed is that both resources and processes are now created dynamically. Another change is that inheritance is supported. A third change is that the mechanisms for operation invocation-call and send-and operation implementation-proc and in-have been extended and integrated. Consequently, all of local and remote procedure call, rendezvous, dynamic process creation, asynchronous message passing, multicast, and semaphores are supported. We have found this flexibility to be very useful for distributed programming. Moreover, by basing SR on a small number of well-integrated concepts, the language has proved easy to learn and use, and it has a reasonably efficient implementation.

. Any multiprocessing facility must include three features: elementary exclusion, data protection, and process saving. While elementary exclusion must rest on some hardware facility (e.g., a test-and-set instruction), the other two requirements are fulfilled by features already present in applicative languages. Data protection may be obtained through the use of procedures (closures or funargs), and process saving may be obtained through the use of the catch operator. The use of catch, in particular, allows an elegant treatment of process saving. We demonstrate these techniques by writing the kernel and some modules for a multiprocessing system. The kernel is very small. Many functions which one would normally expect to find inside the kernel are completely decentralized. We consider the implementation of other schedulers, interrupts, and the implications of these ideas for language design. 1. Introduction In the past few years, researchers have made progress in understanding the mecha...

Efficient synchronization is important for achieving good performance in parallel programs, especially on large-scale multiprocessors. Most synchronization algorithms have been designed to run on a dedicated machine, with one application process per processor, and can suffer serious performance degradation in the presence of multiprogramming. Problems arise when running processes block or, worse, busy-wait for action on the part of a process that the scheduler has chosen not to run. In this paper we describe and evaluate a set of scheduler-conscious synchronization algorithms that perform well in the presence of multiprogramming while maintaining good performance on dedicated machines. We consider both large and small machines, with a particular focus on scalability, and examine mutual-exclusion locks, reader-writer locks, and barriers. The algorithms we study fall into two classes: those that heuristically determine appropriate behavior and those that use scheduler information to guid...

This paper traces the important steps in the history --up to around 1990-- of research on reasoning about programs. The main focus is on sequential imperative programs but some comments are made on concurrency. Initially, researchers focussed on ways of verifying that a program satisfies its specification (or that two programs were equivalent). Over time it became clear that post facto verification is only practical for small programs and attention turned to verification methods which support the development of programs; for larger programs it is necessary to exploit a notation of compositionality. Coping with concurrent algorithms is much more challenging -- this and other extensions are considered briefly. The main thesis of this paper is that the idea of reasoning about programs has been around since they were first written; the search has been to find tractable methods.

In this report, we present a powerful new synchronisation mechanism called scheduling predicates. These predicates---there are no, there exists and for all --- allow the programmer to schedule the order of execution of operations based on relative arrival times, values of parameters, and built-in synchronisation counters. Since many synchronisation problems are, in fact, scheduling problems, these facilitate much simpler and clearer solutions to such problems. We also show that this mechanism subsumes and unifies the existing declarative synchronisation mechanisms used in some object-oriented languages, and extends the number of problems for which a purely declarative approach is possible. 1 Introduction There has been extensive research into developing powerful synchronisation mechanisms. The approaches taken generally fall into one of two categories. Firstly are procedural mechanisms which combine synchronisation primitives with sequential flow control constructs and data structure...

The term Inheritance Anomaly has been introduced into Object-Oriented Concurrent Programming (OOCP). It has also been shown how different kinds of synchronization mechanisms fall into one of the three anomalies. Guarded Methods are shown to be an inadequate tool to solve either History-only Sensitive Anomaly or Modification of Acceptable States. This paper argues that any of the anomalies can be solved by Guarded Methods when a suitable semantics is found for it. The main contribution of the paper is the exposition that the concept of Guarded Methods, provided Guarded Methods are interpreted as Conditional Critical Regions, is an adequate language tool for expressing synchronization constraints in OOCP. Guarded Method based solutions are given for the above mentioned two cases of anomalies. 1 Introduction The concept of Inheritance Anomaly has been introduced into Object-Oriented Concurrent Programming (OOCP) in [MWY90] and further developed in [MY93, MTY93]. 1 It was shown that e...