Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
A probe effect in concurrent programs
Gait J. Software--Practice & Experience16 (3):225-233,1986.Type:Article
Date Reviewed: Sep 1 1986

We have all experienced programs which, like children, behave perfectly when being monitored, but cease to do so as soon as they are unleashed in a real environment. In this short paper, the author is concerned with this effect in the context of concurrent programs. He terms a “probe effect” any change in the correctness of execution, which results when delays are introduced into concurrent programs which contain errors in the synchronization logic. Correct programs would clearly be immune to the insertion of extra delay. Incorrect ones may sometimes start to work correctly, though having failed to do so without the delay; alternatively, a previous, apparently functioning program may cease behaving correctly when unrelated program modifications introduce extra delays.

The paper describes experiments done to investigate the nature of this probe effect. A varying number of identical tasks, incorporating a typical synchronization error of a misplaced semaphore operation when writing to shared memory, were run concurrently under the nondeterministic scheduling of UNIX V7. In the given program, correct final values could sometimes arise even for some incorrect sequences of writes. Synchronization errors were detectable by both incorrect final values in the shared memory and incorrect sequences of writes in a log file of memory operations provided by the CBUG debugging environment. (CBUG also provided the means of introducing varying delays between the statement executions in the program.)

Experiments were done varying the number of processes and the interstatement delay. The ratio of successful runs for each configuration was plotted against the inserted delay. Success was considered first as a correct final value, reached after a correctly ordered sequence of write operations. Later it was considered simply as a correct final value, ignoring “shared memory side-effects” of incorrect write sequences. All of the graphs show the same phenomenon--they indicate a stable region in which uniformly correct behavior results from large values of the delay, thus masking the logic error. For small values of the delay, there is a very unstable region, in which a small change to the delay produces very large changes in the proportion of successful runs. It is in this area that extra delays introduced with trivial program changes can have dramatic effects on the successful behavior of a program.

The paper is an exciting and tantalizing introduction to a new way of looking at certain program malfunctions. Having been shown the phenomenon, though, it is a pity that there is not more in the way of discussion, particularly in attempting to relate the onset of the unstable behavior with the size of other delays in the system.

Reviewer:  Benedict Heal Review #: CR110618
Bookmark and Share
 
Tracing (D.2.5 ... )
 
 
Monitors (D.2.5 ... )
 
 
Synchronization (D.4.1 ... )
 
 
Concurrent Programming (D.1.3 )
 
Would you recommend this review?
yes
no
Other reviews under "Tracing": Date
Experience with a portable debugging tool
Steffen J. Software--Practice & Experience 14(4): 323-334, 1984. Type: Article
Feb 1 1985
Effectiveness of trace sampling for performance debugging tools
Martonosi M., Gupta A., Anderson T. ACM SIGMETRICS Performance Evaluation Review 21(1): 248-259, 1993. Type: Article
Jul 1 1994
Optimally profiling and tracing programs
Ball T., Larus J. ACM Transactions on Programming Languages and Systems 16(4): 1319-1360, 1994. Type: Article
Jul 1 1995
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy