Integrated Concurrency Analysis in a Software Development Environment

Integrated Concurrency Analysis in a Software Development EnvironmentMichal YoungRichard N. TaylorKari ForesterDebra BrodbeckICS DepartmentUniversity of CaliforniaIrvine, CA 92717AbstractThe inherent di�culties of analyzing concurrent softwaremake reliance on a single technique or a single monolithictool unsatisfactory. A better approach is to apply multipleanalysis and veri�cation techniques by coordinating the ac-tivities of a variety of small tool components. We describehow this approach has shaped the design of a set of tool com-ponents to support concurrency analysis in the Arcadia-1software development environment. Implementation and ex-perience with key components is described.1 IntroductionThe goal of analysis, veri�cation, and testing is to demon-strate that a piece of software satis�es the objectives forwhich it was developed. There are no panaceas in this en-deavor; no single technique so dominates others that a mono-lithic tool or environment for supporting that technique issu�cient for the production of quality software.Concurrency adds an additional level of di�culty to allthe major forms of analysis. Formal veri�cation of individ-ual modules must be augmented with cooperation or non-interference proofs, testing strategies must be adjusted tocope with non-determinism, and static analysis techniquesmust deal with the inherent complexity of decision problemsfor concurrent systems.Lacking any single solution to the problem of analyzingconcurrent software, the only practical approach is to sup-port a variety of techniques so that each may be used whereapplicable. Moreover, e�ective tool support for each tech-This work was supported in part by the National Science Foun-dation under grant CCR-8704311, with cooperation from the DefenseAdvanced Research Projects Agency (ARPA Order 6108, ProgramCode 7T10), by the National Science Foundation under grants CCR-8451421 and CCR-8521398, Hughes Aircraft (PYI program), andTRW (PYI program).M. Young is now with the Dept. of Computer Sciences, Purdue Uni-versity. K. Forester is now with Dept. of Computer Science, Univer-sity of Massachusetts, Amherst. D. Brodbeck is now with Dept. ofComputer Science, University of Pittsburgh.

nique must not only aid in the application of that particulartechnique, but also support integration by taking advantageof information obtained from, and provide further informa-tion to, other analysis techniques.The remainder of this paper is organized as follows: Sec-tion 2 describes design considerations for integrating tool-supported analysis techniques, with particular attention toreachability analysis. Section 3 describes the ConcurrencyAnalysis Tool Suite (Cats), a set of tool components to sup-port reachability analysis and related techniques in a soft-ware development environment. Section 4 describes expe-rience applying Cats to several variations on a well-knownproblem. Section 5 describes how such a toolset can be em-bedded in a software development environment, arguing thatin such a setting reachability analysis can contribute to anoverall analysis process and overcome some of the weaknessesit encounters when applied in isolation. Section 6 concludes.2 Analysis approachGeneral analysis model. If one wishes to integrate toolsupport for multiple analysis techniques, it is useful to placeeach technique in the same general model. A variety of anal-ysis and testing techniques can be framed in the generalmodel presented in Figure 1. An abstract representationof the system is constructed, and from it a representationof possible behaviors is constructed. This representation ofpossible behaviors is checked against a speci�cation of ac-ceptable behaviors, and violations of the speci�cation are re-ported. This basic framework is general enough to describetesting (where the model is a program, the representationof behaviors is a set of actual runs, and the checking pro-cedure is the test oracle), reachability analysis (where therepresentation of behaviors is a state-transition graph), andconstrained expression analysis [ADWR86, DAW88] (wherethe representation of behaviors is a set of inequalities, andthe checking procedure is a linear inequality solver), amongmany others.11With only a slight stretch of the imagination, one can even placeformal veri�cation in this framework: The model is the program, aug-mented by auxiliary variables or control predicates; the speci�cationincludes assertions in the program; and the representation of actualbehavior consists of a set of theorems derived from the program, ax-iom schemata, and rules of inference. The program is accepted ifeach assertion in the speci�cation also appears in the representationof actual behavior. This does not re ect the usual division of a veri�-cation system into a veri�cation condition generator (which combinesinformation from the program and speci�cation to produce logical for-mulas) and a theorem prover, but the analogy may help in thinking1 of 10

SystemModel CheckingProcedure(Oracle)Speci�cationFormulasExecutionModeler ErrorReportsBehaviorsFigure 1: Generic skeleton of a program analysis techniqueReachability analysis. The term \reachability analysis"is used to describe construction of a state-transition modelof larger modules (or a complete system) from models ofindividual processes. The composite state-transition modelis often called a \reachability graph." These models typi-cally highlight synchronization structure and abstract awayother details of execution. Reachability analysis has beenapplied to Petri nets and CSP-like and CCS-like state ma-chine models, among others [Apt83, Tay83b, Pet81, MR87].A primary use of reachability analysis is veri�cation of prop-erties of the synchronization structure of software, e.g., free-dom from deadlock, freedom from starvation, and freedomfrom dangerous parallelism. With respect to these proper-ties, reachability analysis provides the same level of assur-ance as formal veri�cation. Reachability graphs can also beused to support other veri�cation and validation techniques,as described in Section 5.Reachability analysis su�ers from two major problems.First, the details abstracted away in the simpli�ed modelsmay be essential to the correctness of software. Omittingthese details often has the e�ect of producing spurious errorreports. Second, the size of a global model usually grows asthe product of the sizes of individual process models. More-over, basic complexity results [Lad79, Tay83a, Smo84] implythat there is no universally applicable short-cut without fur-ther sacri�cing accuracy.When reachability analysis tools are organized along thelines of Figure 1, they �t nicely into an integrated approachto analysis of concurrent software. Analysis of the struc-ture of a system is a prerequisite for constructing the systemmodel, since analysis of a large system will require parcelinginto a set of subsystems. The speci�cation formulas checkedduring analysis of one module may include not only prop-erties explicitly asserted by the programmer, but also prop-erties implicitly speci�ed for all concurrent systems (e.g.,freedom from deadlock), and additional properties that areassumed in the analysis of other modules.2 Both the rep-resentation of possible behaviors and the record of possibleviolations of speci�ed behavior are information that can bemade available to other analysis techniques.The general model of Figure 1 need not re ect the actualorganization of a tool, but we argue below that it is a gooddecomposition for reachability analysis tools.about how formal veri�cation can be combined with other techniques.2For instance, decomposition into \weak monitors" as described in[YT88] depends not only on structural analysis to ensure that depen-dencies among weak monitors are acyclic, but also on verifying thateach weak monitor presents an interface to higher-level modules thatcan be modeled as simple procedure calls.

Design considerationsThe design of Cats instantiates the general framework ofFigure 1 with tool components in a manner driven by lessonsfrom previous implementations of similar systems, namely:� Separate modeling from analysis.� Separate semantics of the model representation fromthe semantics of the actual system.The following paragraphs discuss these rules, how they werein uenced by other reachability analysis systems, and howthey were applied to the design of Cats.Separate modeling from analysis. It is tempting totightly couple modeling (construction of a reachabilitygraph) with analysis. For instance, one could easily com-bine generation of successor states with a check for deadlock,perhaps avoiding some redundant computations. An ear-lier prototype tool for analyzing concurrent Ada programs,constructed at UCI, did just that [Wam85]. In some otherreachability analysis tools, analysis of a reachability graphis kept strictly separate from generation of the graph. In thePNut system for analysis of Petri nets [Raz87, MR87], reach-ability graphs are built by one program and analyzed by acompletely separate program, with communication betweenthe two only via the �le system or Unix pipes. Importantbene�ts accrue from this separation:� The analysis component can be used with di�erentmodeling approaches. In PNut, a complete reachabil-ity graph can be generated by the Reachability GraphBuilder (RGB) tool, or a single trace can be generatedby the Petri net simulator. A trace is a degeneratereachability graph, so the Reachability Graph Analyzer(RGA) tool can be applied to the output of either mod-eling tool.� The analysis component may be used with di�erentmodels. A temporal logic model checking tool con-structed at Carnegie Mellon [CBES85] has been appliedto models of sequential circuits as well as concurrentsoftware.� Both the modeling component and the analysis compo-nent are likely to be simpler.This factoring of analysis from modeling need not im-ply a sequential two-phase operation in which all model-ing precedes all analysis, although current operating systemsubstrates make that the easiest way to compose tool com-ponents. The goal is to maintain a logical separation ofmodeling and analysis, and a clean interface between them,without ruling out tight integration and feedback from theanalysis component to the modeling component.Well-de�ned internal representations. Modeling toolsfor Petri nets or other models with simple operational seman-tics have obvious advantages over tools for directly modelingmore complex phenomena such as concurrent software writ-ten in a language such as Ada or CSP. The usual approachto modeling software is to �rst build a simpli�ed model ofthe complex artifact, and then to model executions of thesimpli�ed representation. An important lesson learned fromearlier prototypes noted above is that the advantages of this2 of 10

translation accrue only if the simpli�ed model has an oper-ational semantics independent of the original artifact. Thatis, one must be able to decompose the question� Does the modeling tool accurately model behaviors ofthe softwareinto the two simpler questions� Is the simpli�ed representation an accurate3representation of the original artifact, and� Does the modeling tool correctly model behaviors of thesimpli�ed representation.If the operational semantics of the simpli�ed represen-tation is de�ned by reference to the original artifact (e.g.,\node type X represents an Ada entry call,") this decompo-sition is lost. This makes it more di�cult to assure oneselfthat the modeling process is accurate or to diagnose theproblem when it is not. Lacking an independent semanticsfor the simpli�ed representation, development of the mod-eling tool depends on reasoning about the original artifact.When the combination of translation and modeling fails, thetool developer cannot easily localize the problem to an in-adequate representation on the one hand or a failure of themodeling tool on the other.3 An analysis toolset for concurrentprogramsThe Concurrency Analysis Tool Suite (Cats) is a set of con-currency analysis tool components designed particularly forintegration with other testing, analysis and veri�cation toolsin a software development environment. The basic tech-niques supported by Cats are reachability analysis and tem-poral logic model checking, and the initial target is analysisof concurrent Ada programs. The design of Cats re ects thekey separations (modeling from analysis, and model seman-tics from semantics of the original artifact) discussed above.Environment context. Cats is intended to be oneamong many sets of tool components in the Arcadia-1software development environment [TBC+88]. Within thelarger Arcadia e�ort, the Team research project is creatinga framework in support of extensible integration and ex-perimentation for automated software testing and analysistechniques [CRZ88]. In addition to the design considerationsdescribed above, Cats re ects basic design principles of theTeam framework, viz., modularity, generic components, andlanguage independence.The Team framework divides analysis support into an en-vironment support level, language processing support, basicanalysis components and advanced testing capabilities. TheCats system as a whole is an instance of an advanced testing3It is also necessary to say precisely what one means by \accurate."One approach is to insist that a model represent all and only the pos-sible behaviors of a piece of software (both accurate and precise, inthe terminology of [Tay83b] and [DAW88]). However, a model thatmeets this absolute standard cannot overcome fundamental complex-ity bounds (e.g., undecidability or NP-hardness), because the relationbetween model and original artifact amounts to a problem reduction.A reasonable approach is to insist that a model represent all possibleerroneous behaviors, but allow the possibility that some impossibleerroneous behaviors are also represented. A precise de�nition of thiscriterion, with su�cient conditions for ensuring it, are described in[You88].

capability. It utilizes the environment support level (e.g., forpersistence of intermediate results), the language processingtools (for producing simpli�ed models of software to be ana-lyzed), and basic analysis components (primarily a symbolicinterpretation system).CATS architectureThe organization of tool components that comprise theCATS system �ts the general model of Figure 1. That is,a representation of possible behaviors is constructed froma system model, and in a separate process the behaviorsare checked against a speci�cation of required behaviors.A more detailed diagram of information ow in the Catssystem is presented in Figure 2. The system model is aset of state-transition graphs called task interaction graphs(TIG's) [LC89]. TIG's are derived from the source code of aconcurrent Ada program or other design notation for concur-rent systems. A compiler front end produces a semantically-analyzed graph representation of the program, and this rep-resentation is then translated into TIG's. An exhaustiveenumeration of all possible sequences of interactions amongtasks is represented by a state-transition graph called a taskinteraction concurrency graph (TICG). Explicit speci�ca-tions in a branching-time propositional temporal logic arechecked using the decision procedure described by Clarke,Emerson, and Sistla [CES86], and a separate procedure ver-i�es freedom from deadlock. Behaviors that violate thespeci�cation formulas may be reported directly to the user,or may �rst be re�ned by attempting symbolic executionof a corresponding path through the program as describedin [YT88].Task Interaction Concurrency Graphs. A task inter-action concurrency graph (TICG) represents all the possiblebehaviors of set of interacting task interaction graphs. Thenodes of TICG are tuples of task interaction graph nodes,representing reachable states of the system (or subsystem)under analysis. Edges in the TICG represent interactionsbetween individual processes (tasks).In general, the size of a task interaction concurrency graphmay be the product of the sizes of the individual task interac-tion graphs from which it is constructed. Exhaustive globalanalysis of large systems can never be practical, so parcel-ing of analysis is an absolute requirement. The granular-ity to which systems must be divided for analysis dependson space e�ciency, fast traversal, and locality of referencein the representation of TICG's. A reasonable goal is thatthe maximum practical granule size should be large enoughthat, when a system is divided into modules in design, eachnatural module can be analyzed in whole. This requiresgraphs representing thousands of states and events to beconstructed and analyzed in a few minutes.The Team framework suggests an organization thatclearly separates the generic aspects of reachability graphsfrom those aspects of TICG's dependent on the language ofthe software under analysis (e.g., Ada). As it happens, a de-sign that isolates language-dependent features also serves thee�ciency needs of reachability analysis by improving localityof reference. For these reasons, task interaction concurrencygraphs in Cats are divided into two parts: A language-3 of 10

IRISabstract syntaxgraphTaskInteractionGraphs TemporalLogicModelCheckerTemporal LogicAssertions Anomalousevent sequencesTIGGER ConcurrencyGraphBuilder ErrorReportsTask InteractionConcurrency Graph

SymbolicExecution(ARIES)AnnotatedAdaCompilerFrontEnd AssertionExtractorFigure 2: Information ow among tool components in CATS.independent attributable graph structure, and a set of at-tributes.The graph structure underlying a TICG contains no at-tributes except for the connectivity of the reachability graph.The attributable graph structure is completely independentof whether the reachability graph is built from task inter-action graphs, a Petri net, or some other model. Statesand events are represented as attributes of nodes and edges,respectively, of the basic attributable graph structure. At-tributes are encapsulated separately from the graph struc-ture.For space and time e�ciency, a parallel array structure isused for representing the graph structure and its attributes(see Figure 3). This results in good locality of reference,since a typical reference pattern is to traverse the wholegraph while accessing only one or two attributes. In partic-ular, checking temporal logic speci�cation formulas involvesa traversal for each subformula, and in each traversal one ortwo boolean attributes is accessed and another is produced.An interesting example of reuse of the generic attributablegraph structure underlying TICG's is a special-purpose, in-ternal representation of task interaction graphs. Just priorto constructing a TICG, a very optimized internal repre-sentation of task interaction graphs is built (with, e.g., allidenti�ers of tasks and entries replaced by small integers),and references to the original structure are treated as at-tributes of the graph. The original structure of TIG's re ectsa di�erent set of design tradeo�s than reachability graphs:Task interaction graphs of individual tasks are much smallerthan TICG's, so compromising abstraction for performance

would be inappropriate. They are instead represented byan attributed graph structure automatically generated byP-Graphite [WWFT88]. P-Graphite manages persistence ofTIG's, allowing them to exist beyond the lifetime of a sin-gle program without explicit input/output. The last-secondtranslation of this representation into optimized form allowsCats to increase performance without losing all the bene�tsof the P-Graphite-based representation.Checking sequencing constraintsCats checks two kinds of sequencing conditions on the be-havior of concurrent software as modeled by a TICG. Free-dom from deadlock is considered an implicit speci�cation,and is checked using a special-purpose procedure. Addi-tional constraints can be explicitly speci�ed by the user, byembedding temporal logic assertions in the software. Tem-poral logic assertions are checked using an adaptation of themodel checking algorithm of [CES86]. When a sequencingerror is detected, example violating behaviors (sequences ofevents) are produced. These violating behaviors are cur-rently used only for reporting errors to the user; in the fu-ture they will �rst be checked for feasibility using symbolicexecution.Temporal logic assertions. The temporal logic sup-ported by Cats is a propositional, branching time logicbased on the computation tree logic (CTL) of [CES86]. Butwhereas the propositions in a CTL formula refer to states(nodes of a reachability graph), it is often more convenient4 of 10

6Array ofnodes Array of edges123456Array ofStateDescriptions123456 Attributable graph(language-independent)TICG(Ada-speci�c)Additionalattributes �rstindices (logical pointers)of states and attributes�rstlinkFigure 3: Division of task interaction concurrency graphs (TICG's) into a language-independent attributable graph structureand a set of attributes, using a parallel array structure for e�ciency and to allow easy creation of new attributes. For simplicity,only attributes of states (nodes) are shown here; edges (events) are attributed in a similar manner.to describe sequences of events. Temporal logic assertionsembedded in Ada programs must describe tasking events,which are represented by edges in a TICG.Cats evaluates assertions about sequences of task inter-actions. Assertions are built up from event descriptions,the usual boolean connectives, and the temporal opera-tors eventually (AF, in the notation of [CES86]), always(AG), until (AU), and potentially (EF). The formula(accept task1.entry1 or accept task2.entry2) de-scribes events that represent the conclusion of a rendezvouseither at entry entryname of task1, or at entry entry2 oftask2. The formula (eventually accept task.entry) de-scribes a set of states (those states from which every exe-cution path leads eventually to conclusion of a rendezvousat task.entry, in this case). State formulas may be furthercomposed with boolean and temporal connectives. In theformula (eventually (eventually accept t.e)), the twolexical occurrences of eventually are semantically distinct:The operand of the inner occurrence is an event description,and the operand of the outer occurrence is a state descrip-tion.Model checking. As in the design of the reachabilitygraph representation, a main objective in designing the tem-poral logic checking component of the system was to isolatelanguage dependencies. This is accomplished by separatingthe processing of atomic propositions, which describe indi-vidual events (edges) and states (nodes), from the logicalconnectives which are independent of the attributes associ-ated with nodes and edges (see Figure 4).The atomic propositions of each subexpression in a tem-poral logic assertion are patterns that match attributes ofindividual states or edges in a task interaction concurrencygraph. These descriptions are the only part of the tem-poral logic that depend on the language-dependent aspectsof task interaction concurrency graphs. A single module(the atomic proposition evaluator of Figure 4) is responsible

for determining which nodes and edges match a description.The current version matches descriptions of Ada task inter-actions. If the model checking component of Cats were tobe used for a di�erent language or model (say, Petri nets),then this module could be replaced by a suitable procedurefor checking atomic propositions (e.g., markings of the net).Each temporal logic assertion is parsed into an expressiontree. Internal nodes of the tree hold boolean and tempo-ral connectives and external nodes hold atomic propositions.The overall checking procedure traverses the tree bottom up,associating with each sub-expression a boolean attribute ofnodes or edges in the reachability graph. It dispatches tothe atomic proposition evaluator when evaluating leaves,and for internal nodes to a language-independent module(the model checker in Figure 4) that depends only on thelanguage-independent attributable graph structure.Temporal logic assertions are embedded in the user'ssource code. Each program location may be representedby many states in the TICG. The set of TICG states corre-sponding to the location of a single assertion is termed the\context" of the assertion. A relation is maintained betweenan assertion and its context, and a sequencing violation isreported only if a temporal assertion evaluates to FALSE inthe context of the assertion. This is accomplished by treat-ing the context essentially as another atomic proposition,and treating the whole assertion as an implication with thecontext as premise.4 Example applicationsBoth Cats and the environment into which Cats will even-tually be placed are currently under construction. Some ofthe major components of Cats are already operational, andwe have applied these to some well-known problems.What works, what doesn't. The �rst stage of Cats isa translation from source code to TIG models. This trans-5 of 10

TIG modelof programTICGbuilder AttributablegraphStates Temporal logicformulasAtomicpropositionevaluator Values ofatomicpropositionsModelchecker Values ofsubformulasLanguageindependentcomponentslogicalpointersinformation owKey:

(shared key)Figure 4: Many of the components of Cats are independent of the particular system model. In the initial version, thelanguage-dependent parts (outside the dashed line) model concurrent Ada programs. The model-independent portions can bereused for other reachability analysis capabilities, e.g., of executable design notations. The dotted lines represent the logicalpointer relation illustrated in Figure 3. Values of atomic propositions and assertion subformulas are boolean attributes of thegraph structure.lation utilizes a compiler front-end that is shared with avariety of analysis capabilities in the Team framework. Cur-rently, a parser for Ada is operational, but static semanticanalysis is still in development, as is the translation fromthe semantically-analyzed intermediate form to TIG struc-tures. In lieu of automatically generated TIG structures, thecurrently operational reachability graph (TICG) generatoraccepts TIG's generated from hand-coded descriptions. Atemporal logic model checking procedure is also operational,as are facilities for extracting temporal logic assertions fromthe internal representation of a program. A special-purposeprocedure for detecting deadlock is also operational. The re-lation between assertions, source code, and TIG's, which willeventually be maintained automatically, is currently simu-lated by a correspondence between identi�ers in TIG's andin an intermediate (post�x) form of assertions. And whileexperiments with a symbolic interpretation system have be-gun, integration of symbolic execution into the operationalsystem is still in the design stages; one of the experimentsdescribed below simulates the contribution of symbolic eval-uation to concurrency analysis.The following experiments were performed with the cur-rently operational portions of Cats. In other words, weproduced a TIG representation of a concurrent program byhand, along with temporal logic assertions. The remainderof the processing | building the TICG, checking it for dead-lock and for conformance with temporal logic formulas, and

generation of example behaviors | was automatic.Dining PhilosophersThe dining philosophers problem is a well-known example ofexposure to deadlock. It is attractive for experimentationprimarily because so many other developers of tools andtechniques for analyzing concurrent software have used it,facilitating comparisons. Moreover, it is a simpli�ed versionof a signi�cant class of problems for concurrent systems. Weassume the reader has some familiarity with the problem.Experiment 1: Capacity and performance. The �rstversion of the dining philosophers considered is the classic(non-)solution, in which all n philosophers remain seated atthe table and each picks up the left fork before the right. Inthis version deadlock occurs when each philosopher holds onefork. In this case analysis is trivial, once the TICG is built.The interesting questions concern capacity and performanceof tool components, which will be important in determiningthe granularity of modules that must be achieved for prac-tical analysis of large systems.The dining philosophers system consists of 2n processes(Ada tasks), one for each philosopher and fork. Using anunoptimized representation of the tasks, in which each com-munication (fork up, or fork down) is represented by twodistinct interactions (beginning and end of Ada rendezvous),6 of 10

the performance of the TICG builder, compiled under VerdixAda 5.41 and measured on a Sun 3/260, are as follows:4Philosophers Tasks States Edges Minutes (approx)2 4 40 56 < 13 6 268 576 < 14 8 1792 5168 15 10 11,744 42,440 7This experiment suggests that a reasonable granularity isin the neighborhood of 8 processes, for processes with simplesynchronization structure. While global analysis of largesystems will certainly not be feasible, they can be analyzede�ciently if broken into modules of no more than about 6or 8 processes.The times given above include only building the TICG.For the 4-philosopher problem, deadlock checking took halfa minute and produced a report of a sequence of task inter-actions leading to the single deadlocked state:Deadlock Violation Detected:Engage phil1, fork1.upFinish phil1, fork1.upEngage phil2, fork2.upFinish phil2, fork2.upEngage phil3, fork3.upFinish phil3, fork3.upEngage phil4, fork4.upFinish phil4, fork4.upphil1 attempting to engage fork4.upphil2 attempting to engage fork1.upphil3 attempting to engage fork2.upphil4 attempting to engage fork3.upfork1 attempting to accept fork1.downfork2 attempting to accept fork2.downfork3 attempting to accept fork3.downfork4 attempting to accept fork4.downExperiment 2: Resource ordering. The diningphilosophers experiment was repeated, with the modi�cationthat an ordering is imposed on forks and each philosopherpicks up its lower-numbered fork �rst. This is a well-knownapproach to deadlock avoidance, and had the expected e�ect:The deadlocked state that is detected in the �rst version ofthe dining philosophers is absent in the version with resourceordering.The size of the TICG, time to generate it, and time tocheck each state for deadlock are approximately the same asfor the �rst version of the dining philosophers problem.Temporal logic checking. After freedom from deadlockwas veri�ed in the four-philosopher system with resourceordering, the following temporal logic assertion was checked:(always (eventually accept fork1.up) and(eventually accept fork2.up) and(eventually accept fork3.up) and(eventually accept fork4.up))Together with the FIFO acceptance of queued entry callsguaranteed by Ada, this property should guarantee thatphilosophers never starve. If the task scheduler is unfair,though, the property may not hold. A sequence of eventsviolating the constraint is reported to the user:4These are approximate elapsed times, obtained from the Unixtime command, and were not obtained under controlled conditions(variations ranging up to a factor of 2 were observed). Times in tablesare always for building the TICG, and do not include checking fordeadlock or violations of temporal logic formulas. In every case, theanalyses were much faster than building the TICG.

Engage phil1, fork1.upFinish phil1, fork1.upEngage phil1, fork4.up<<LOOP>>Finish phil1, fork4.upEngage phil1, fork1.downFinish phil1, fork1.downEngage phil1, fork4.downFinish phil1, fork4.downEngage phil1, fork1.upFinish phil1, fork1.upEngage phil1, fork4.upA version of the model checker that will allow the user toassume fair scheduling (using the extended CTL algorithmsof [CES86]) is under development.Experiment 3: Butler. Another well-known solution tothe dining philosophers problem is the addition of a \butler"process, which ensures that the number of philosophers atthe table is one fewer than the number of forks. The butlertask is as follows:task body butler isroom occupants: natural := 0;room limit: constant natural := problem size � 1;beginloop selectwhen room occupants < room limit =>accept enter;room occupants := room occupants + 1;oraccept leave;room occupants := room occupants � 1;end select;end loop;end butler;Each philosopher is modi�ed to enter the room beforepicking up either fork, and to leave the room after eating.When the number of philosophers in the room reaches thelimit (one less than the number of forks), the butler refuses tolet another philosopher enter until some philosopher leaves,thus avoiding the deadlock situation.Addition of the butler task, combined with additionalcomplexity in each philosopher, adds considerably to the sizeof the generated TICG. With four philosophers (9 tasks), atable over ows and causes the analysis procedure to termi-nate after 35 minutes of processing.Philosophers Tasks States Edges Minutes (approx)2 5 139 250 < 13 7 1681 4188 < 14 9 * * > 35The dining philosophers problem with a butler illustratesone of the problems of concurrency analysis, namely, that itabstracts away variable values even when those values arecritical to the synchronization structure of a system. In thepresent case, abstracting away the variable room_occupantscauses an inaccurate representation of the behavior of thebutler | it fails to prevent all the philosophers from simul-taneously entering the room. When the TIG model of diningphilosophers with a butler was analyzed, it reported a dead-lock that cannot actually occur.7 of 10

Experiment 3a: Unrolling the butler. A partial solu-tion to the problem of spurious error reports is to combinestatic concurrency analysis with symbolic execution. Else-where [YT88], we have described an approach in which can-didate errors exposed by static concurrency analysis are usedto guide a symbolic executor. Cats is designed to supportthis approach, as indicated in Figure 2. However, neitherthe symbolic execution capabilities of the Aries generic in-terpretation system [ZE88] nor the remainder of Cats is yetmature enough to test this combination.An alternative way to combine symbolic execution withstatic concurrency analysis is to \unroll" the butler. Everyprogrammer knows that complexity of control ow can oftenbe traded for ags and counters. Symbolic execution canbe used to automate a translation from ags or countersto control ow, similar to loop unrolling in an optimizingcompiler. For a �xed value of room_limit, the butler taskcan be unrolled into:loop select �� room occupants = 0;accept enter;select �� room occupants = 1;accept enter;select �� room occupants = 2;accept enter;�� Etc. until room occupants = room limitor accept leave;end select;or accept leave;end select;oraccept leave;�� ERROR: room ocupants = �1end select;end loop;The count of philosophers in the room is replaced bynesting copies of the loop body. At each step in the un-rolling, the guard predicate room_occupants < room_limitevaluates either to TRUE or FALSE, and can be discarded.When it evaluates to FALSE, the unrolling process termi-nates (the innermost copy of the select clause containsonly the accept leave alternative). The eventual termi-nation of the unrolling process guarantees that the value ofroom_occupants will never exceed a �xed maximum value,but information in the butler task alone is not su�cient toverify that it cannot be decremented after reaching zero.For this reason, the outermost accept leave alternative isassociated with an error state in the TIG representation;absence of this state in modeled executions can be checkedautomatically.A TIG representation of the unrolled version of the butlerwas constructed, and analysis was repeated with this ver-sion. Note that, even though the unrolled version of butleris larger than the original, it does not cause the TICG tobecome larger. This will always be the case when an elimi-nated variable was used to keep track of the states of otherprocesses, since the value of the variable is purely a function

of the states of other tasks.Philosophers Tasks States Edges Minutes (approx)2 5 56 59 < 13 7 932 1856 < 14 9 12,694 35,615 5Given a fair task scheduler, each philosopher will have anin�nite number of opportunities to eat provided the butlerin�nitely often lets a philosopher into the room. The as-sertion (always (eventually accept butler.enter))wasveri�ed by the temporal logic model checker. For the fourphilosopher problem, building the TICG and checking theassertion were completed in under 6 minutes of elapsed time.Experiment 4: Parceling analysis. Global reachabil-ity analysis of large systems is impractical, so they mustbe parceled for independent analysis. Cats does not yetattempt to parcel large systems, but it is not di�cult tosimulate a parceled analysis scheme. A further variation ofthe dining philosophers problem with resource ordering wasconstructed, in which the philosophers and forks make up asingle module of a larger system. In this variation, philoso-phers eat and then think only in response to requests foradvice from other processes. This module was analyzed ac-cording to the \weak monitors" parceling scheme describedin [YT88]. A combination of deadlock checking and tempo-ral logic model checking was used to verify that the modulemet the requirements of the parceling scheme. Analysis ofa system with two philosophers, two forks, and two dummyprocesses representing the remainder of the system took ap-proximately �ve minutes.5 DiscussionThe reachability analysis capabilities of Cats are limited bythemselves. But, as mentioned earlier, Cats is not intendedto be used as a stand-alone analysis tool. In the contextof a complete software development environment, there is agood prospect for overcoming the shortcomings of reacha-bility analysis, and in this context reachability analysis canbe a useful addition to other analysis methods. This sectionbrie y considers possible bene�ts of combining reachabilityanalysis with other analysis techniques, and the environmentsupport needed to realize those bene�ts.Other analysis techniquesTesting. A basic premise of most approaches to softwaretesting is that programs are characterized by input-outputpairs, and that output is completely determined by input.In concurrent software, output is usually not completely de-termined by input (because of apparent non-determinism inprocess schedulers) and output values may not even be themost important property of software.Recognizing these di�culties, some researchers have for-mulated testing approaches suited speci�cally for concur-rent programs. Taylor and Kelly [TK86] described a set ofstructural coverage criteria for concurrent programs, basedon a concurrency state graph representation of the system.Tai [Tai85] described a method for reproducing sequences of8 of 10

synchronizations in concurrent programs to address the re-producible testing problem associated with concurrent sys-tems. To accomplish this, he de�ned a sequencing controltask, much like German, Helmbold, and Luckham's moni-tor task [GHL82], which monitors the execution sequence oftasking entry calls. Weiss [Wei88] developed a formal the-ory for reasoning about test coverage of concurrent programsbased on representing the concurrent programs as a set ofsimulating sequential programs termed serializations.Each of these approaches can bene�t from combinationwith reachability analysis tools. The TICG produced byCats is essentially equivalent to the concurrency graphstructure underlying the technique of Taylor and Kelly. Theserializations of Weiss' framework, and the sequences ofsynchronizations required by Tai's approach, correspond topaths in a TICG.Formal veri�cation. Formal veri�cation provides a highlevel of assurance for a wide variety of program proper-ties. Unfortunately, it is an expensive analysis techniqueeven for sequential software. When concurrency is intro-duced, assertions involving individual processes must be aug-mented by auxiliary variables or control predicates involvingother processes, and a cooperation or non-interference proofmust be performed in addition to proofs of individual pro-cesses [OG76, Lam88].Joseph, R�auchle, and Toueg have described an approachto verifying protocols which uses reachability analysis toreduce the complexity of non-interference proofs [JRT86],while reducing the size of the reachability graph by judi-ciously using assertions rather than states to represent someproperties. The combination of symbolic execution withreachability analysis described in [YT88] uses formal veri-�cation techniques (supported by a global symbolic evalua-tor) to ameliorate the problem of spurious error reports fromreachability analysis.Environment supportWe have indicated above some opportunities for combininganalysis techniques, and more detailed descriptions of in-tegrated analysis strategies have appeared elsewhere, e.g.,[YT88, Tay84]. It is also worthwhile to consider how theoverall analysis process might be coordinated in an environ-ment with strong tool support.An environment with strong support for integratinganalysis tools must manage a collection of software artifacts,a collection of facts and allegations about those artifacts, anda collection of tools (or better, tool components) for derivinginformation about a system. Existing analysis results are re-tained where possible, but portions of the system must bereanalyzed if some artifact has been changed or supersededby a more detailed design representation or implementation;or if a new requirement has been established by the user; orif the user has requested a greater level of assurance, e.g.,a property that was previously established by simulation ortesting must now be formally veri�ed.Automated analysis aids must determine which analysistechniques are currently applicable by examining the currentstructure of the evolving system (possibly including multi-ple design representations) and the repository of asserted

properties that have been established or alleged for each arti-fact. The analysis plan should apply the cheapest techniquesavailable to obtain the desired level of assurance. Often itwill not be clear whether a particular technique is adequate,so the analysis plan will involve replanning based on anal-ysis results. Finally, results (which may include indicationsof why particular techniques could not be applied and sug-gestions for guiding reanalysis or restructuring the system)must be communicated to the user and stored for futureuse. In particular, dependencies between results must bestored. For instance, if formal veri�cation of some propertyof module A depends on a property of module B that hasbeen established only by testing, then appropriate caveatsmust be attached to dependencies on A. Dependency man-agement is similar to management of a network of lemmasin a formal veri�cation system, except that we envision itencompassing properties established by a variety of meanswith di�ering degrees of con�dence. Some dependencies willbe obligations for yet-unwritten portions of a system.This paradigm for analysis poses several requirements fortools and for environment support. The domain of applica-bility of each tool and technique must be explicitly stated,so that it is available during formation of the analysis plan.User guidance in applying techniques is acceptable, and inmany cases will be necessary, but to the extent practicalapplicability should be automatically determined. For in-stance, a simple and cheap examination of source code coulddetermine whether it contains input/output assertions andloop invariants required by a veri�cation condition genera-tor.If tools make use of information obtained from other tech-niques, these dependencies must also be explicitly availableso that they may be accounted for in planning analysis andreanalysis. Both intermediate products and the results ofanalysis should be produced in a form suitable for storageand reuse, both within a single analysis session and for futureanalyses. Derivation of useful representations, whether theybe parse trees or owgraphs or reachability graphs, shouldbe an integral part of the analysis plan.Modularity and separation of concerns are accepted prin-ciples for designing any large system. Particular designchoices for decomposing Cats were made so that it could �tin an integrated analysis scheme like that described above,supported by the object management and process program-ming facilities of the Arcadia-1 environment infrastructure.Separation of the portion of Cats that derives a TIG modelfrom the portion that generates a reachability graph servesnot only to leverage from language-processing capabilities inthe environment, but also to enable analyses in the process-planning stage to determine whether reachability analysis ofparticular modules is likely to be feasible. Generation of theTICG (reachability graph) is separated from analysis notonly to make those two processes simpler but to enable useof the TICG in other analyses.6 ConclusionE�ective support for analysis, veri�cation, and testing re-quires coordinated application of a variety of techniques.As the di�culties of analyzing concurrent software are es-pecially severe, so it is especially important that multiple9 of 10

techniques be brought to bear on the problem. The ap-proach advocated here allows each technique to make use ofinformation gathered by other techniques.Cats is designed to be integrated with other tools andtechniques in a software development environment. It re-quires structural information to allow decomposition oflarge systems for independent analysis, and it producesinformation useful in other techniques, particularly sym-bolic execution and testing. In keeping with the Teamframework [CRZ88] and the Arcadia environment archi-tecture [TBC+88], Cats is composed of small tool frag-ments to maximize exibility and reuse. Language-speci�cand language-independent components are clearly separated,and major parts of each are reusable.Both Cats and the Arcadia-1 environment into whichCats will be placed are still in development. Experiencewith the operational portions of Cats make us optimisticabout the role static concurrency analysis can play in com-bination with other techniques for analyzing concurrent soft-ware.Acknowledgments. As Cats is a cooperative project be-tween the University of California, Irvine, the University ofMassachusetts, Amherst, and Wellesley College, we must be-gin by acknowledging our partners at the latter two institu-tions: Lori Clarke, Doug Long, W. Richards Adrion, JosephFialli, and Chris Ho�man. Their contributions to Cats arenot adequately represented in the current paper, but some ofit has been described elsewhere [LC89], and more papers willundoubtedly be forthcoming. We have also bene�ted fromthe example of an earlier prototype tool for static concur-rency analysis, built at UCI by Gordon Wampler. We havebene�ted from the advice of Rami Razouk and Tim Mor-gan, regarding their experience building reachability analysistools based on Petri nets, and from continuing discussionswith Debra Richardson regarding symbolic evaluation andtesting.References[ADWR86] George S. Avrunin, Laura K. Dillon, Jack C. Wileden,and William E. Riddle. Constrained expressions: Addinganalysis capabilities to design methods for concurrentsoftware systems. IEEE Transactions on Software En-gineering, SE-12(2):278{292, February 1986.[Apt83] Krzysztof R. Apt. A static analysis of CSP programs. InProceedings of the Workshop on Program Logic, Pitts-burgh, PA, June 1983.[CBES85] E. M. Clarke, M. C. Browne, E. A. Emerson, and A. P.Sistla. Using temporal logic for automatic veri�cationof �nite state systems. In K.R. Apt, editor, Logics andModels of Concurrent Systems, pages 3{26. Springer-Verlag, Berlin, 1985.[CES86] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Auto-matic veri�cation of �nite-state concurrent systems us-ing temporal logic. ACM Transactions on ProgrammingLanguages and Systems, 8(2):244{263, April 1986.[CRZ88] Lori A. Clarke, Debra J. Richardson, and Steven J. Zeil.Team: A support environment for testing, evaluation,and analysis. In Proceedings of ACM SIGSOFT '88:Third Symposium on Software Development Environ-ments, pages 153{162, November 1988. Appeared asSigplan Notices 24 (2) and Software Engineering Notes13 (5).[DAW88] Laura K. Dillon, George S. Avrunin, and Jack C. Wile-den. Constrained expressions: Toward broad applica-bility of analysis methods for distributed software sys-tems. ACM Transactions on Programming Languagesand Systems, 10(3):374{402, July 1988.

[GHL82] Steven M. German, David P. Helmbold, and David C.Luckham. Monitoring for deadlocks in Ada tasking. InProceedings of the AdaTEC Conference on Ada, pages10{25, Arlington, VA, October 1982.[JRT86] Thomas A. Joseph, Thomas Rauchle, and Sam Toueg.State machines and assertions: An integrated approachto modeling and veri�cation of distributed systems. Sci-ence of Computer Programming, 7(1):1{22, 1986.[Lad79] Richard E. Ladner. The complexity of problems in sys-tems of communicating sequential processes. In Pro-ceedings of the Eleventh Annual ACM Symposium onTheory of Computing, pages 214{223, Atlanta, Georgia,April 1979.[Lam88] Leslie Lamport. Control predicates are better thandummy variables for reasoning about program control.ACM Transactions on Programming Languages andSystems, 10(2):267{281, April 1988.[LC89] Douglas L. Long and Lori A. Clarke. Task interactiongraphs for concurrency analysis. In Proceedings of theEleventh International Conference on Software Engi-neering, Pittsburgh, May 1989.[MR87] E. Timothy Morgan and Rami R. Razouk. Interactivestate-space analysis of concurrent systems. IEEE Trans-actions on Software Engineering, SE{13(10):1080{1091,October 1987.[OG76] Susan Owicki and David Gries. An axiomatic proof tech-nique for parallel programs. Acta Informatica, 6(4):319{340, 1976.[Pet81] J. Peterson. Petri Net Theory and the Modeling of Sys-tems. Prentice-Hall, Inc., Englewood Cli�s, N.J., 1981.[Raz87] Rami R. Razouk. A guided tour of P-NUT. TechnicalReport 86{25, University of California, 1987.[Smo84] Scott A. Smolka. Analysis of Communicating FiniteState Processes. PhD thesis, Department of ComputerScience, Brown University, 1984. Department of Com-puter Science Technical Report No. CS-84-05.[Tai85] K. C. Tai. Reproducible testing of concurrent Ada pro-grams. In Proceedings of SoftFair II, pages 49{56, De-cember 1985.[Tay83a] Richard N. Taylor. Complexity of analyzing the synchro-nization structure of concurrent programs. Acta Infor-matica, 19:57{84, 1983.[Tay83b] Richard N. Taylor. A general-purpose algorithm for an-alyzing concurrent programs. Communications of theACM, 26(5):362{376, May 1983.[Tay84] Richard N. Taylor. Analysis of concurrent software by co-operative application of static and dynamic techniques.In Hans-Ludwig Hausen, editor, Software Validation,pages 127{137. North-Holland, 1984.[TBC+88] Richard N. Taylor, Frank C. Belz, Lori A. Clarke, LeonOsterweil, Richard W. Selby, Jack C. Wileden, Alexan-der L. Wolf, and Michal Young. Foundations for the Ar-cadia environment architecture. In Proceedings of ACMSIGSOFT '88: Third Symposium on Software Devel-opment Environments, pages 1{13, Boston, November1988. Appeared as Sigplan Notices 24 (2) and SoftwareEngineering Notes 13 (5).[TK86] Richard N. Taylor and Cheryl D. Kelly. Structural testingof concurrent programs. In Proceedings of the Workshopon Software Testing, pages 164{169,Ban�, Canada, July1986. ACM/SIGSOFT and IEEE-CS Software Engineer-ing Technical Committee.[Wam85] Gordon Kent Wampler. Static concurrency analysis ofAda programs. Master's thesis, University of California,Irvine, 1985.[Wei88] Stewart N. Weiss. A formal framework for the studyof concurrent program testing. In Proceedings of theSecond Workshop on Software Testing, Analysis, andVeri�cation, pages 106{113, Ban�, Canada, July 1988.ACM/SIGSOFT and IEEE-CS Software EngineeringTechnical Committee.[WWFT88] Jack C. Wileden, Alexander L. Wolf, Charles D. Fisher,and Peri L. Tarr. PGRAPHITE: An experiment in persis-tent typed object management. In Proceedings of ACMSIGSOFT '88: Third Symposium on Software Develop-ment Environments, pages 130{142, Boston, November1988.10 of 10

[You88] Michal Young. How to leave out details: Error-preservingabstractions of state-space models. In Proceedings of theSecond Workshop on Software Testing, Analysis, andVeri�cation, pages 63{70, Ban�, Canada, July 1988.[YT88] Michal Young and Richard N. Taylor. Combining staticconcurrency analysis with symbolic execution. IEEETransactions on Software Engineering, 14(10):1499{1511, October 1988.[ZE88] Steven J. Zeil and Edward C. Epp. Interpretation ina tool-fragment environment. In Proceedings of theTenth International Conference on Software Engineer-ing, pages 241{248, Singapore, April 1988.

11 of 10