home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3283 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  2.0 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!mips!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!marick
  2. From: marick@m.cs.uiuc.edu (Brian Marick)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Testing Parallel Components
  5. Message-ID: <1992Aug22.171919.5977@m.cs.uiuc.edu>
  6. Date: 22 Aug 92 17:19:19 GMT
  7. References: <1992Aug21.160553.22273@evb.com> <1992Aug21.213902.8000@cactus.org>
  8. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  9. Lines: 33
  10.  
  11. wiley@cactus.org (Mark S. Wiley) writes:
  12.  
  13. >It depends on what type of parallel software you are testing.  When I
  14. >was testing Sequent's symmetric multiprocessor OS (Dynix/ptx) I wrote a
  15. >parallel test driver to run 100's to 1,000's of test processes in
  16. >parallel.  This tends (-: to put it mildly :-) to stress the operating
  17. >system and expose previously unknown race conditions in the OS.
  18.  
  19. Some colleagues and I did a similar thing when testing for locking
  20. problems in a multiprocessing version of System V.  Because I'd just
  21. spent some time working on a flexible coverage tool, we were able to
  22. go one step further.
  23.  
  24. We were worried about whether our tests stressed what they were
  25. supposed to stress.  It seemed possible that our tests might
  26. bottleneck in one part of the system, leaving other parts only lightly
  27. exercised. We devised "race coverage" to measure whether that
  28. happened.
  29.  
  30. Race coverage counts how often a thread (processor) enters a routine
  31. while another thread is already in it.  We ran existing stress
  32. tests, measured their race coverage, then designed more stress tests
  33. to fill in the gaps.  They found bugs.
  34.  
  35. We learned some good rules of thumb for writing stress tests, and
  36. dabbled a bit with extensions to race coverage, but we didn't take it
  37. as far as it could go.  I'd like to do that someday.
  38.  
  39. For more about race coverage, see my GCT documentation.  To get that,
  40. start by fetching cs.uiuc.edu:pub/testing/GCT.README
  41.  
  42. Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick, marick@testing.com (pending)
  43. Testing Foundations:  Consulting, Training, Tools.
  44.