Deterministic execution testing of concurrent Ada programs

The authors show how to accomplish deterministic execution debugging of a concurrent Ada program according to a given synchronization (SYN) sequence. They first define the format of a SYN sequence of a concurrent Ada program in order to provide sufficient information for deterministic execution. They show how to transform a concurrent Ada program P into a slightly different Ada program P' so that any execution of P' with (X,S) as input, where S is the SYN sequence of a previous execution of P with input X, definitely repeats S. Tools for transforming concurrent Ada programs for deterministic execution debugging are described.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

A language-based approach to deterministic execution debugging of concurrent Ada programs is presented. The approach is to define synchronization (SYN)-sequences of a concurrent Ada program in terms of Ada language constructs and to replay such SYN-sequences without the need for system-dependent debugging tools. It is shown how to define a SYN-sequence of a concurrent Ada program in order to provide sufficient information for deterministic execution. It is also shown how to transform a concurrent Ada program P so that the SYN-sequences of previous executions of P can be replayed. This transformation adds an Ada task to P that controls program execution by synchronizing with the original tasks in P. A brief description is given of the implementation of tools supporting deterministic execution debugging of concurrent Ada programs. >

State-cover testing for nondeterministic terminating concurrent programs with an infinite number of synchronization sequences

Regarding the progress made in model analysis, more complex models, and consequently more complex programs can now be analyzed. However, this remains a difficult task in particular for concurrent programs which induce a lot of combinatory. Another way to reduce this complexity is to use program decomposition. Program decomposition technics extract a part of a given program while preserving the behavior of the original program w.r.t. a specified property. Quasar analyzes concurrent Ada programs, using program slicing as decomposition technic. The program slicer is built using the ASIS tools, that provides syntactic and semantic informations on an Ada source code. These informations can be considered as the “semantic and syntactic graph” mapping an Ada program. This allows to save building the graphs used by traditional program slicing technics and thus to design a simpler and more evolutive algorithm.This paper presents Yasnost, the program slicer used by Quasar, describes the method used to slice concurrent Ada programs and illustrates with two significant examples how concurrent programs analysis can take advantage of program slicing for reducing the analyzed program complexity.KeywordsDependence GraphData DependenceOriginal ProgramConcurrent ProgramTransitivity GraphThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This paper proposes two new types of basic program dependences in concurrent programs, named the synchronization dependence and the communication dependence, and a new program representation for concurrent Ada programs, named the Task Dependence Net (TDN). The task dependence net can be used as a unified representation in a concurrent Ada programming environment.KeywordsData DependenceProgram RepresentationSequential ProgramConcurrent ProgramException HandlerThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Recently, the author proposed two new types of basic program dependences in concurrent programs, named the synchronization dependence and the communication dependence, and a new program representation for concurrent Ada programs, named the Task Dependence Net (TDN), which extends the usual program dependence graph for sequential programs to the case of concurrent Ada programs. This article discusses some potential applications of the task dependence net in Ada software development activities including program understanding, testing, debugging, maintenance, and complexity measure/metrics.

This paper presents a static analysis method based on extended Petri nets to detect tasking deadlocks and livelocks in a class of concurrent Ada programs. We model the tasking behavior of concurrent Ada programs using extended Petri nets and analyze the Petri net model of an Ada program using an algebraic method. We show that detection of a tasking deadlock or livelock in a concurrent Ada program can be reduced to getting a positive integer solution for a matrix equation concerning the Petri net model of the program. The method is effective for those concurrent Ada programs that include no dynamic creation of tasks, no abort statement, and no exception handler.

Concurrent Ada dead statements detection

Software testing generally proceeds as follows: generating test-cases, selecting test-data, executing a test target program, inspecting execution result and evaluating whether testing has already been sufficient or not yet. As for methods for structural testing of programs, the way using a coverage, where the coverage means what extent given testing criteria are satisfied, is noted. At the evaluating step, whether or not we finish the testing is determined in view of the coverage. This paper proposes a method for structural testing of concurrent programs written in Ada programming language, especially, test-case generation and execution of the programs. The Event InterActions Graph (EIAG) is used as a model for concurrent programs. The EIAG consists of Event Graphs and Interactions. An Event Graph is a control flow graph of a program unit in a concurrent program. The Interactions represent interactions between the program units. Program units are such as procedures, functions and task-types. After generating test-cases on the EIAG, a method for selecting test-data is described and measures to cope with infeasible test-cases with which are generated in this step is clarified. And a forced execution of a test target concurrent program in order to solve the nondeterministic execution is investigated. The nondeterministic execution is characteristic of concurrent programs.

The Java language supports the use of monitors, sockets, and remote method invocation for concurrent programming. Also, Java classes can be defined to simulate other types of concurrent constructs. However, concurrent Java programs, like other concurrent programs, are difficult to specify, design, code, test and debug. In this paper, we describe the design of a toolset, called JaDA (Java Dynamic Analyzer), that provides testing and debugging tools for concurrent Java programs. To collect run-time information or control program execution, JaDA requires transformation of a concurrent Java program into a slightly different Java program. We show that by modifying Java classes that support concurrent programming, Java application programs only need minor modifications. We also present a novel approach to managing threads that are needed for testing and debugging of concurrent Java programs.

Tasking communication deadlock is one of most typical synchronization errors in concurrent Ada programs. In this article, we specify four kinds of tasking communication deadlocks, i.e., Circular-entry-calling, Dependence-blocking, Termination-blocking, and Acceptance-blocking. We also discuss briefly how to detect such deadlocks.

Although a lot of research has been done in software testing, how to test concurrent programs effectively has not received much attention. Two early papers on testing concurrent programs were written by P. Brinch Hansen (see Software-Practice and Experience, vol.8, p.145-50 and p.721-9 (1989)) K.C. Tai's paper (1985) addressed several issues on testing concurrent programs and started the work on deterministic execution testing and debugging of concurrent programs. These and other research results on testing concurrent programs are briefly examined. The following approaches to testing concurrent programs are discussed: single execution testing, multiple execution testing, and deterministic execution testing. Problems in deterministic execution testing and debugging of concurrent programs are examined. >

Internet-based concurrent programs, such as multiplayer online game program that multiplayer in highly interactive domain behave in space-time unpredictably, offer more advantages and are difficult to test because of their non-deterministic behaviors. One approach to test the concurrent programs is reachability testing. Lei and Carve did more research work and proposed an algorithm for reachability testing. Lei's algorithm can not ensure that a race variant is always feasible because all the events that occur after the race receive event r can potentially be affected, which may induce exercising false SYN-sequences after the send partner of r of a synchronization pair is changed. For increasing the feasibility of reachability testing, we can remove all the events that occur after the race receive event r after changing the send partner of r. But the problem that we need to solve is how to remove. We propose a feasible strategy to solve the problem. Our strategy uses vector timestamps to determine the happened-before relation between the race receive events of the synchronization pairs of the concurrent program. According to the happened-before relation, we change the send partners of the more receive events in proper order. After we change the send partner of the race receive event r , we need to remove all the events that occur after r in the original execution. Our strategy can ensure the feasibility of race variants. The case study proves that our feasible strategy for reachability testing of the concurrent programs can ensure the feasibility of the testing.

Attention is given to the problems that arise during the testing and debugging cycle of concurrent programs because of their nondeterministic execution behavior, whereby multiple executions of a concurrent program with the same input may exercise different synchronization sequences and even produce different results. These problems are solved by using deterministic execution debugging and testing. The purpose of deterministic execution debugging to to replay executions of a concurrent program so that debugging information can be collected. Examples of semaphores and monitors are used to illustrate the approach and the process of designing replay tubes is described. The use of regression testing to see if earlier debugging and testing introduced new errors, is examined.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Concurrent programs are more difficult to test than sequential programs because of non-deterministic behavior. An execution of a concurrent program non-deterministically exercises a sequence of synchronization events called a synchronization sequence (or SYN-sequence). Non-deterministic testing of a concurrent program P is to execute P with a given input many times in order to exercise distinct SYN-sequences. In this paper, we present a new testing approach called reachability testing. If every execution of P with input X terminates, reachability testing of P with input X derives and executes all possible SYN-sequences of P with input X. We show how to perform reachability testing of concurrent programs using read and write operations. Also, we present results of empirical studies comparing reachability and non-deterministic testing. Our results indicate that reachability testing has advantages over non-deterministic testing.