University of Kansas Electrical EngineeringComputer Science
Jerry James and Douglas NiehausInformation and Telecommunication Technology Center
Electrical Engineering and Computer Science DepartmentUniversity of Kansas
{james,niehaus}@ittc.ku.edu
A Method for Providing Complete Access to the
Concurrent Programming Model
University of Kansas Electrical EngineeringComputer Science
Overview
• Problem• Irreproducible Concurrent Behavior
• Background• Definitions and Terms
• Solution• Programming Environment Enhancements
– Record and Control
• Implementation• Conclusions
University of Kansas Electrical EngineeringComputer Science
Problem
• Concurrent software is important to many people • Wide range of applications and contexts
• None of it is subject to scientifically valid experimentation• Irreproducible behavior based on concurrency control• Programming model does not constrain interleaving of
concurrent components
• Concurrency control errors are often intermittent• Happen in a few of all possible component interleavings
• Problematic target for model driven programming
University of Kansas Electrical EngineeringComputer Science
Background• Multi-threading is one common form of concurrency
• Distribution is another
• Thread events include:• Instruction execution (Basic Blocks)
• Context Switch, Signals, Read/Write, System Calls
• History of a thread is the set of events it experiences
• History of a computation is the interleaving of the thread histories
• Complete event history would be reproducible because it would include every relevant event• Everything affecting thread behavior and interleaving
University of Kansas Electrical EngineeringComputer Science
Solution• Record Computation Event History
• All important computation events
• Interleaving of computation thread histories
• Message arrival for distributed computations
• Programming environment support for executing/reproducing a specified history• Recorded, or
• Synthesized
• BERT: implementation pattern enabling recording and control of all important computation events• Multi-threaded and distributed
• Add reproducibility property to programming model
University of Kansas Electrical EngineeringComputer Science
Recording an Event History
• Thread Events• Gathered by adaptation of GCC code profiling
• CPU Instruction Execution is basic thread event• Entry to each Basic Block is an equivalent shorthand
• Basic block is a linear sequence of machine instructions– Entered at a label, Terminated by a jump (mostly)
• Thread interactions with environment• Signals
• Read/Write
• System Calls
University of Kansas Electrical EngineeringComputer Science
Recording an Event History
• A Thread event history is the sequence of events it experiences during execution
• Context switches are not events but note where the computation switches from one thread to another
• A Computation event history is the concatenated segments of the histories of its component threads punctuated by context switches • Distributed computations also track message delivery
University of Kansas Electrical EngineeringComputer Science
History Completeness
• A history is complete when it contains everything required to reproduce computation behavior
• Behaviors contained in “everything” depend on the semantics of the application computation
• Complete set• Instruction execution (Basic Block)• Context Switch• Signals• Read/Write (including messages)• System calls
University of Kansas Electrical EngineeringComputer Science
Reproduce an Event History
• Clever Insight completes the reproduction environment• Adds ability to attach a TCL/GDB script to a breakpoint
• Breakpoints at signal and context switch locations• Clever Insight uses specified history and that produced by
executing program to identify proper breakpoint context
• Requires the ability, from the programming environment, to context switch and deliver signals on demand
• Implemented with breakpoint scripts that take the required action and set the next breakpoint in the history
University of Kansas Electrical EngineeringComputer Science
Synthesize an Event History
• Test interesting concurrency scenarios• Model generated would be great
• Not all history specifications correspond to possible scenarios
• Use Clever Insight to guide execution and thus construct a desired event history• Specify the next context switch or signal point
• Clever Insight sets a breakpoint
• Compares predicted behavior to actual behavior
University of Kansas Electrical EngineeringComputer Science
BThreads: Reproducible Environment
• Compiler modifications for history recording• BThreads is a user-level library implementing the
POSIX multi-thread standard• Provides both recording and control hooks • Encapsulates system calls of interest• Currently limited to CPU-bound computations
• Modified debugger (Clever Insight) for following recorded or synthesized event histories
• Well behaved target for abstract modeling of concurrent implementations of applications
University of Kansas Electrical EngineeringComputer Science
Conclusion
• This addresses a long-neglected concurrent programming need
• Our approach gives control over concurrency, which is necessary for the reproducibility property
• We have constructed a multithreaded example• Another example exists for concurrency arising from
distribution, based on single-machine simulation of the distributed environment• KU-PNNI simulator
University of Kansas Electrical EngineeringComputer Science
Future Work
• Extension to include I/O• Read/Write of files, and reproduction of byte streams
• Capture system call information transfer to computation
• Message histories for distributed computations
• Explicit Modeling support• Execute synthesized event histories
• Instrument model specified data sets
• Post processing comparison of predicted and produced event histories
• Suggestions from modelers ??
Top Related