[net.lang.ada] Testing in a concurrent environment

EBERARD@USC-ISIF.ARPA (Edward V. Berard) (12/24/85)

Back in late November, I sent the following message to this mailing list:

I am looking for some references on testing concurrent software. I am
specifically interested in testing concurrent Ada software, but I would
be interested in any general concurrent software testing methodologies.
I would request that you send your responses directly to me and I will
post a summary to the mailing lists in the header. Thanks in advance.

                                        -- Ed Berard
                                           (301) 251 - 1626

-------

To date I have received a number of responses which I have included in
the rest of this message. I want to thank all who responded.

I am specifically interested in a METHODOLOGY for testing concurrent
software, i.e., a means of *systematically* generating a series of
tests which will uncover the maximum number of errors with the minimum
amount of effort. There seem to be three schools of thought regarding
the testing of concurrent software:

   1) Use some automated tool (most often a "debugger") to catch errors
when they occur. A variation on this approach is the suggestion that a
testing tool be built.

   2) Since the testing of concurrent software is far more difficult
than can reasonably be attempted while the software is executing, the
use of formal (mathematical) proofs of the software is required.

   3) The testing of concurrent software is a relatively "new"
discipline. Therefore, more research is required to establish some form
of strategy for the testing of this software.

We are continuing our research in this area, and would be glad to
discuss this topic with anyone seriously interested in the testing of
concurrent software.

                                        -- Ed Berard

-------

Date:  Tue, 26 Nov 85 12:02 CST
From:  "Paul D. Stachour" <Stachour@HI-MULTICS.ARPA>
Subject:  Re: Testing in a Concurrent Environment
To:  "Edward V. Berard" <EBERARD@USC-ISIF.ARPA>

  Ed, the Honeywell/DDC GCOS6 Ada compiler includes a tasking-debugger.
It automatically stops all other tasks, so that things don't change
while one is looking at them.
  Also, here at HOneywell CSC, we did a distributed-database test
system, where we also "stopped time" to do look-see and monitoring.
I'll ask our secretary to get a copy of the tech-report (if it is not
company-confidential) about it; it was done by Mark Spinrad & others;
 ... Paul

-------

Date:  Tue, 26 Nov 85 12:04 CST
From:  "Paul D. Stachour" <Stachour@HI-MULTICS.ARPA>
Subject:  Re: Testing in a Concurrent Environment
To:  "Edward V. Berard" <EBERARD@USC-ISIF.ARPA>

  By-the-way, the reference for it is found in Honeywell Pub CZ42-00,
available through your honeywell pubs sales office or other contacts.
If you wish to know more about the G6 Multitasking Ada debugger, you
should send a msg to Miner
 at BCO via this machine, i.e.  Miner%BCO -at HI-Multics.
  ...Paul

-------

Date: 27 Nov 85 07:26:00 PDT
From: "CONTR23" <contr23@nosc-tecr>
Subject: Re: Ada Tasking Tools
To: "eberard" <eberard@usc-isif>


Mr. Eberard :

The only real time tasking monitor that I am aware of is a system
being developed at Stanford University by David Luckham.  It is 
basically a monitor that detects deadness errors.  Not sure what
compiler or machine it was implemented on.  A technical report is 
available that describes the monitor(Technical Report No. 83-249),
Stanford will more than likely send you the report if requested.

I have had experience debugging concurrent programs using the 
DEC/Ada symbolic debugger and Verdix/VADS debugger.  Both of 
these tools are helpful, however, limited in scope.

Let me know if I can be of any help.  Looking forward to receiving
your list of concurrent tools in the near future.

-----------------
Jim Baldo Jr.
E-System
ECI Division
P.O. Box 12248
St. Petersburg, FL 33733
813-381-2000 Ext. 4586
CONTR23@NOSC-TECR

------

Date: 27 Nov 1985 10:42:59 PST
Subject: Re: Testing in a Concurrent Environment
From: Grady Booch <GBOOCH@USC-ISIF.ARPA>
To: Edward V. Berard <EBERARD@USC-ISIF.ARPA>


Try:

Anomaly Detection in Concurrent Software and Static Data Flow Analysis by
Taylor and Osterweil (IEEE TOSE [Transactions on Software Engineering],
May 1980).

egb
-------

Date: Wed, 27 Nov 85 13:17:10 cst
From: Mary Pfreundschuh <pfreund%uiowa.csnet@CSNET-RELAY.ARPA>
To: eberard@usc-isif.arpa
Subject: concurrent Ada analysis refs


  Here are three references for algorithms which statically analyze 
  concurrent Ada programs.  The bibliographies in the papers will
  suggest more references.  A seminar class here at Iowa implemented
  Taylor's algorithm given in [Taylor83a].

                              Annotated Refs


        [Taylor80] Taylor, R.N. and  Osterweil, L.J., "Anomaly Detection
            in Concurrent Software by Static Data Flow Analysis",
            IEEE Transactions on Software Engineering, Vol. SE-6, No.
            3 (May 1980), pp. 265-278.


        [Taylor83a] Taylor, R.N., "A General-purpose Algorithm for
            Analyzing Concurrent Programs", Communications of the ACM.,
            Vol. 26, No. 5 (May 1983), pp. 362-376.


        [Taylor83b] Taylor, R.N., "Complexity of Analyzing the Synchroni-
            zation Structure of Concurrent Programs", Acta Informatica,
            Vol. 19 (1983), pp. 57-84.

-------

Date: Wed, 27 Nov 85 15:05:12 est
From: John McHugh <rti-sel!rti!mchugh%mcnc.csnet@CSNET-RELAY.ARPA>
Message-Id: <8511272005.AA29758@rti>
To: eberard@usc-isif.ARPA
Subject: Concurrent testing of Ada

K.C. Tai at North Carolina State University in Raleigh has been doing
research in this area for the last few years.  If you contact him,
please feel free to mention my name.

John McHugh
Research Triangle Institute

McHugh@UTexas

-------

Date: Fri 29 Nov 85 15:39:51-PST
From: Doug Bryan <BRYAN@SU-SIERRA.ARPA>
Subject: Re: Testing in a Concurrent Environment
To: EBERARD@USC-ISIF.ARPA


Ed,

Concerning testing of concurrent s/w:

	Have you read about out experimental annotation language called
	TSL??  Take a look at the proceedings from the Paris Conference
	last spring.  The language is undergoing some changes currently.
	We are adding features that make TSL applicable at the PDL level
	as well as features that make the language more usable in the
	prototyping and debugging stages of s/w dev.

At this time we have the version of the language presented in Paris up-and-
running along with an interactive, symbolic debugger.

doug bryan
stanford university
-------

Date: Mon, 2 Dec 85 22:49:30 CST
From: kaplan@b.CS.UIUC.EDU (Simon Kaplan)
Message-Id: <8512030449.AA02141@b.CS.UIUC.EDU>
To: eberard@usc-isif.arpa
Subject: Testing concurrent software


Hi, I've just received the latest soft-eng bulletin & seen your request.  To
the best of my knowledge (which is admittedly very verification oriented) the
common attitude seems to be that concurrent software is better verified than
tested because of the high degree of nondeterminism introduced by arbitrary
interleavings (or different processor speeds in a truly parallel environment,
for example).  

Now, this is (to put it mildly) an intimidating task.  Fortunately, temporal
logic-based verification systems greatly ease this task, as verification is a 
sort of "formal walk-through" (although those who invented the techniques
may well gag at having their work so described).  At the University of Illinois
I am currently involved in some research involving building verification
tools for languages such as Ada.  I have a student currently building proof
systems, and would be happy to talk to you about this further (i.e., building
a proof system to verify concurrent ada code.  It's not as bad as it sounds).

If you're interested in pursuing this (which is admittedly different from 
testing), please mail back & we can carry this further.

Regards,
Simon Kaplan

(kaplan@b.cs.uiuc.edu)
or, if your mailer doesn't hack domains currently:
(kaplan@uiuc.arpa)

-------

To: EBerard@usc-isif.ARPA
Subject: Testing Concurrent Ada Programs
Date: 03 Dec 85 08:44:09 EST (Tue)
From: Rich Hilliard <rh@mitre-bedford.ARPA>


I've seen two very good articles on the subject of your request.  Both
take the position (and rightly so) that to test, you gotta specify
something to test.  So, they propose specification techniques for Ada
tasking.

	Luckham and Helmbold "TSL: Tasking Specification Language" (in
the fat Ada Letters issue from the Paris conference).

	Nils Klarlund (DDC and Univ. Arrhus), "Formal Concepts for the
Specification and Automatic testing of Ada tasks".  (The copy I have
seems to be a pre-print; I don't think it is published anywhere.  I'll
mail you a copy if you want.)

-------

Date: Tuesday, 3 December 1985 16:49:52 EST
From: Dan.Miller@a.sei.cmu.edu
To: eberard@usc-isif.arpa
Subject: Testing in a Concurrent Env.

I think you will find the last article in the March '85 (vol. 11, num. 3)
issue of IEEE Transactions of Soft. Eng. by Taylor and Standish of interest.
You can contact Dick Taylor at Univ. of Cal. at Irvine over the Internet:
taylor@uci.

Hope this helps...

--- Daniel "Dan" H. MIller                Software Engineering Institute
dhm@sei.cmu.edu (dhm@cmu-sei.arpa)        Carnegie-Mellon University
(412)578-7700                             Pittsburgh, PA 15213 USA

"Disclaimer:  The  views  and  conclusions  are those of the author, and
should not be interpreted as representing the official policies,  either
expressed or implied, of any organization he may be affiliated with."

-------