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 ??