1 / 13

A Method for Providing Complete Access to the Concurrent Programming Model

A Method for Providing Complete Access to the Concurrent Programming Model. Jerry James and Douglas Niehaus Information and Telecommunication Technology Center Electrical Engineering and Computer Science Department University of Kansas {james,niehaus}@ittc.ku.edu. Overview. Problem

hugha
Télécharger la présentation

A Method for Providing Complete Access to the Concurrent Programming Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Method for Providing Complete Access to the Concurrent Programming Model Jerry James and Douglas Niehaus Information and Telecommunication Technology Center Electrical Engineering and Computer Science Department University of Kansas {james,niehaus}@ittc.ku.edu

  2. Overview • Problem • Irreproducible Concurrent Behavior • Background • Definitions and Terms • Solution • Programming Environment Enhancements • Record and Control • Implementation • Conclusions

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

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

More Related