Communicating Java Threads

The incorporation of multithreading in Java may be considered a significant part of the Java language, because it provides udimentary facilities for concurrent programming. However, we belief that the use of channels is a fundamental concept for concurrent programming. The channel approach as described in this paper is a realization of a systematic design method for concurrent programming in Java based on the CSP paradigm. CSP requires the availability of a Channel class and the addition of composition constructs for sequential, parallel and alternative processes. The Channel class and the constructs have been implemented in Java in compliance with the definitions in CSP. As a result, implementing communication between processes is facilitated, enabling the programmer to avoid deadlock more easily, and freeing the programmer from synchronization and scheduling constructs. The use of the Channel class and the additional constructs is illustrated in a simple application

A distributed Real-Time Java system based on CSP

CSP is a fundamental concept for developing software for distributed real time systems. The CSP paradigm constitutes a natural addition to object orientation and offers higher order multithreading constructs. The CSP channel concept that has been implemented in Java deals with single- and multi-processor environments and also takes care of the real time priority scheduling requirements. For this, the notion of priority and scheduling has been carefully examined and as a result it was reasoned that priority scheduling should be attached to the communicating channels rather than to the processes. In association with channels, a priority based parallel construct is developed for composing processes: hiding threads and priority indexing from the user. This approach simplifies the use of priorities for the object oriented paradigm. Moreover, in the proposed system, the notion of scheduling is no longer connected to the operating system but has become part of the application instead

An Approach for Minimizing Spurious Errors in Testing ADA Tasking Programs

We propose an approach for detecting deadlocks and race conditions in Ada tasking software. It is based on an extension to Petri net-based techniques, where a concurrent program is modeled as a Petri net and a reachability graph is then derived and analyzed for desired information. In this approach, Predicate-Action subnets representing Ada programming constructs are described, where predicates and actions are attached to transitions. Predicates are those found in decision statements. Actions involve updating the status of the variables that affect the tasking behavior of the program and updating the Read and Write sets of shared variables. The shared variables are those occurring in sections of the program, called concurrency zones, related to the transitions. Modeling of a tasking program is accomplished by using the basic subnets as building blocks in translating only tasking-related statements and connecting them to produce the total Predicate-Action net model augmented with sets of shared variables. An augmented reachability graph is then derived by executing the net model. Deadlocks and race conditions are detected by searching the nodes of this graph. The main advantage offered by this approach is that the Predicate-Action extension of the net leads to pruning infeasible paths in the reachability graph and, thus, reducing the spurious error reports encountered in previous approaches. Also, this approach enables a partial handling of loops in a practical way. Implementation issues are also discussed in the paper

Graph models for reachability analysis of concurrent programs

Reachability analysis is an attractive technique for analysis of concurrent programs because it is simple and relatively straightforward to automate, and can be used in conjunction with model-checking procedures to check for application-specific as well as general properties. Several techniques have been proposed differing mainly on the model used; some of these propose the use of flowgraph based models, some others of Petri nets.This paper addresses the question: What essential difference does it make, if any, what sort of finite-state model we extract from program texts for purposes of reachability analysis? How do they differ in expressive power, decision power, or accuracy? Since each is intended to model synchronization structure while abstracting away other features, one would expect them to be roughly equivalent.We confirm that there is no essential semantic difference between the most well known models proposed in the literature by providing algorithms for translation among these models. This implies that the choice of model rests on other factors, including convenience and efficiency.Since combinatorial explosion is the primary impediment to application of reachability analysis, a particular concern in choosing a model is facilitating divide-and-conquer analysis of large programs. Recently, much interest in finite-state verification systems has centered on algebraic theories of concurrency. Yeh and Young have exploited algebraic structure to decompose reachability analysis based on a flowgraph model. The semantic equivalence of graph and Petri net based models suggests that one ought to be able to apply a similar strategy for decomposing Petri nets. We show this is indeed possible through application of category theory

Hybrid analysis techniques for software fault detection

Since the question "Does program P obey specification S" is undecidable in general, every practical software validation technique must compromise accuracy in some way. Testing techniques admit the possibility that a fault will go undetected, as the price for quitting after a finite number of test cases. Formal verification admits the possibility that a proof will not be found for a valid assertion, as the price for quitting after a finite amount of proof effort. No technique so dominates others that a wise validation strategy consists of applying that technique alone; rather, effective validation requires applying several techniques

Specification and validation of control-intensive integrated circuits in hopCP

technical reportControl intensive ICs pose a significant challenge to the users of formal methods in designing hardware. These ICs have to support a wide variety of requirements including synchronous and asynchronous operations, polling and interrupt-driven modes of operation, multiple concurrent threads of execution, complex computations, and programmability. In this paper, we illustrate the use of formal methods in the design of a control intensive IC called the "Intel 8251" Universal Synchronous/Asynchronous Receiver/Transmitter (USART), using our formal hardware description language 'hopCP'. A feature of hopCP is that it supports communication via asynchronous ports (distributed shared variables writable by exactly one process), in addition to synchronous message passing. We show the usefulness of this combination of communication constructs. We outline static analysis algorithms to determine safe usages of asynchronous ports, and also to discover other static properties of the specification. We discuss a compiled-code concurrent functional simulator called CFSIM, as well as the use of concurrent testers for driving CFSIM. The use of a seraantically well specified and simple language, and the associated analysis/simulation tools helps conquer the complexity of specifying and validating control intensive ICs

Specification and validation of control intensive ICs in hopCP

technical reportControl intensive ICs pose a significant challenge to the users of formal methods in designing hardware. These ICs have to support a wide variety of requirements including synchronous and asynchronous operations polling and interrupt driven modes of operation multiple concurrent threads of execution non-trivial computational requirements and programmability. In this paper we illustrate the use of formal methods in the design of a control intensive IC called the "Intel 8251" Universal Synchronous / Asynchronous Receiver Transmitter (USART), using our hardware description language 'hopCP'. A feature of hopCP is that it supports communication via synchronous ports in addition to synchronous message passing Asynchronous ports are distributed shared variables writable by exactly one process We show the usefulness of this combination of communication constructs We outline algorithms to determine safe usages of asynchronous ports and also to discover other static properties of the specification We discuss a compiled code concurrent functional simulator called CFSIM, as well as the use of concurrent testers for driving CFSIM. The use of a semantically well specified and simple language and the associated analysis/simulation tools helps conquer the complexity of specifying and validating control intensive ICs

hopCP: A concurrent hardware description language

Journal ArticlehopCP is a language for the specification, simulation, and synthesis of hardware systems. hopCP captures the behavior of a hardware system by specifying the causal relationships between actions that the system can perform. No specific timing discipline is implied by a hopCP specification. Hence, hopCP specifications can be implemented as synchronous, asynchronous, or mixed synchronous and asynchronous circuits. Salient features of hopCP include nonatomic actions, synchronous and asynchronous styles of value communication, broadcast channels, a purely functional sublanguage to express the computational aspects of hardware behavior, and an efficient tool (called parComp) to infer the composite behavior of a collection of hopCP modules. Operational Semantics of hopCP in terms of labeled transition systems is presented. A few examples are described to illustrate the expressive power of hopCP. A summary of the implementation is also presented

Programming Languages for Distributed Computing Systems

When distributed systems first appeared, they were programmed in traditional sequential languages, usually with the addition of a few library procedures for sending and receiving messages. As distributed applications became more commonplace and more sophisticated, this ad hoc approach became less satisfactory. Researchers all over the world began designing new programming languages specifically for implementing distributed applications. These languages and their history, their underlying principles, their design, and their use are the subject of this paper. We begin by giving our view of what a distributed system is, illustrating with examples to avoid confusion on this important and controversial point. We then describe the three main characteristics that distinguish distributed programming languages from traditional sequential languages, namely, how they deal with parallelism, communication, and partial failures. Finally, we discuss 15 representative distributed languages to give the flavor of each. These examples include languages based on message passing, rendezvous, remote procedure call, objects, and atomic transactions, as well as functional languages, logic languages, and distributed data structure languages. The paper concludes with a comprehensive bibliography listing over 200 papers on nearly 100 distributed programming languages