No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Belvedere: Prototype of a Pattern Oriented Debugger for Highly Parallel Computation.
... Animation facilities help in following the progress of execution "instantaneously" in each thread of control [HoC87], [PaU89], [HoC90], [SBN89], [ZeR91], [Ho91]. The focus of animation is mapping Ε to P. ...
... An animation facility can help in resolving some of these ambiguities in the E → P part of the cycle. Animation facilities [HoC87], [PaU89], [McH89], [Ho91] provide an instantaneous view of the mapping of events of a time-process graph to a graphical structure. This, however, translates into extra effort for the user who must then develop a graphical structure that can support animation [HoC90], [SBN89], [Ho91], [ZeR91]. ...
Debugging is a process that involves establishing relationships between several entities: The behavior specified in the program, P, the model/predicate of the expected behavior, M, and the observed execution behavior, E. The thesis of the unified approach is that a consistent representation for P, M and E greatly simplifies the problem of concurrent debugging, both from the viewpoint of the programmer attempting to debug a program and from the viewpoint of the implementor of debugging facilities. Provision of such a consistent representation becomes possible when sequential behavior is separated from concurrent or parallel structuring. Given this separation, the program becomes a set of sequential actions and relationships among these actions. The debugging process, then, becomes a matter of specifying and determining relations on the set of program actions. The relations are specified in P, modeled in M and observed in E. This simplifies debugging because it allows the programmer to think in terms of the program which he understands. It also simplifies the development of a unified debugging system because all of the different approaches to concurrent debugging become instances of the establishment of relationships between the actions.
The unified approach defines a formal model for concurrent debugging in which the entire debugging process is specified in terms of program actions. The unified model places all of the approaches to debugging of parallel programs such as execution replay, race detection, model/predicate checking, execution history displays and animation, which are commonly formulated as disjoint facilities, in a single, uniform framework.
We have also developed a feasibility demonstration prototype implementation of this unified model of concurrent debugging in the context of the CODE 2.0 parallel programming system. This implementation demonstrates and validates the claims of integration of debugging facilities in a single framework. It is further the case that the unified model of debugging greatly
simplifies the construction of a concurrent debugger. All of the capabilities previously regarded as separate for debugging of parallel programs, both in shared memory models of execution and distributed memory models of execution, are supported by this prototype.
... De façon complémentaire, l'observation de l'exécution se concentre sur un instantané de l'exécution à un moment donné, et peut donc montrer plus d'informations. Celle−ci peut prendre différentes formes, adaptées aux particularités du système, et peut être animée pour montrer l'évolution de l'état de l'exécution (Hough [34], Socha [76], Jamrozik [38]). ...
Our goal is to provide a debugging assistance for parallel and distributed applications based on persistent objects which allows cyclical debugging and offers a high level of abstraction for the observation of an execution. The nondeterminism and the probe effect of this kind of execution make bugs caused by race conditions difficult to correct. The limitations of both static analysis and dynamic approaches based on a current execution justify the choice of a debugging methodology based on replay, which solves the problem of nondeterminism by recording an execution. In this case the behavior of an incorrect execution is well known and can be visualised in specific views according to the particularities of the execution environment. In the context of object-oriented systems, we define a debugging record/replay (control driven) system based on the objects which allows cyclical debugging and object execution observation. The reexecution and the observation services are designed and integrated in a modular architecture. These concepts have been applied to the Guide system. A reexecuting kernel has been implemented using Guide objects, which automatically records and replays an execution.
... is a trace-based, post-mortem debugger. It provides animations of program behavior both in terms of primitive simulator events and in terms of abstract events from user-defined perspectives. Belvedere assists only with parallel programming errors; it does not provide any aid errors in the sequential sections of code.[Hough Cuny 1987] Cray Directory of Supercomputer Applications SoftwareThe following information is based on[Supercomputer 1987].The Cray Directory of Supercomputer Applications Software is published by Cray Research, Inc., and it is updated every six months. The January 1987 issue contained on the order of 400 software entries. Two-thirds of the entries ...
... Generating and collecting event traces in distributed systems is a very useful technique for studying and analyzing the run-time behavior of such systems. For this reason, the distributed systems research community has given considerable attention to this subject 11,13,33,35,38,50,54 . This process is also referred to, in literature, as collecting the event history". ...
... The monitor must be made aware of observable events performed by the program. This reporting can take place either at run time [4,5,6], where the monitor executes concurrently with the program, or during post-execution analysis [7,8]. We feel that run time monitoring is preferable because it enables the monitor to be used in conjunction with other run time testing tools and provides a monitoring capability for programs which (may) never terminate. ...
We address the problem of correctly monitoring the run time behavior of a concurrent program. We view a program as having three (potentially different) sets of behavior: computations of the original program when monitoring is not performed, computations after the monitor is added to the program, and "observations" produced by the monitor. Using these sets of behaviors, we define four properties of monitor systems: non- interference, safety, accuracy and correctness. We define both a minimal level and a total level for each of these properties. The non-interference and safety properties address the degree to which the presence of the monitor alters a computation (the differences between the first two sets of computations) . Accuracy is a relationship between a monitored computation and the observation of the computation produced by the monitor. Correctness is a relationship between observations and the unmonitored computations. A run time monitor for TSL-1 and Ada has been implemented. This monitor system uses two techniques for constructing the observation. We show that any monitoring system using these two techniques is at least minimally correct, from which the (minimal) correctness of the TSL-1 monitor follows.
... Browsing-The event history is examined possibly through the use of specialized tools. Examination methods range from text editors to "movies" showing the state changes caused by events [Hough and Cuny 1987; Le Blanc and Robbins 19851. Replay-The debugger uses the event history to control a reexecution of the program. ...
The main problems associated with debugging concurrent programs are increased complexity, the 'probe effect', nonrepeatability, and the lack of a synchronized global clock. The probe effect refers to the fact that any attempt to observe the behavior of a distributed system may change the behavior of that system. For some parallel programs, different executions with the same data will result in different results even without any attempt to observe the behavior. Even when the behavior can be observed, in many systems the lack of a synchronized global clock makes the results of the observation difficult to interpret. This paper discusses these and other problems related to debugging concurrent programs and presents a survey of current techniques used in debugging concurrent programs. Systems using three general techniques are described: traditional or breakpoint style debuggers, event monitoring systems, and static analysis systems. In addition, techniques for limiting, organizing, and displaying a large amount of data produced by the debugging systems are discussed.
... One efficient method is to store performance data into databases. The Belvedere system [6] organises performance data using relational database. It allows the user to access the information by means of database queries. ...
Designing an efficient parallel program usually involves iteration of performance tuning. During this process a very large amount of performance data is produced. Without a proper software tool, the process of performance tuning can be very complicated and tedious. In this paper we describe a performance tuning tool for message passing programs. Our tool uses a relational approach to organise the performance data and analyse the program performance through the visualisation technique. Various graphical displays which assist the user to fine tune the performance of message passing programs are discussed. 1 Introduction In a message-passing system, one of the most important features is its interprocessor communication facilities. When designing a message-passing program, one must consider the problem of task allocation and the communication among tasks. It is generally not difficult to decompose a problem into sections, and execute these sections on different processors. However, design...
We describe a high-level debugging approach, Event-Based Behavioral Abstraction 1995, in which debugging is treated as a process of creating models of expected program behaviors and comparing these to the actual behaviors exhibited by the program. The use of EBBA techniques can enhance debugging-tool transparency, reduce latency and uncertainty for fundamental debugging activities, and accommodate diverse, heterogeneous architectures. Using events and behavior models as a basic mechanism provides a uniform view of heterogeneous systems and enables analysis to be performed in well-defined ways. Their use also enables EBBA users to extend and reuse knowledge gained in solving previous problems to new situations. We describe our behavior-modeling algorithm that matches actual behavior to models and automates many behavior analysis steps. The algorithm matches behavior in as many ways as possible and resolves these to return the best match to the user. It deals readily with partial behavior matches and incomplete information. In particular, we describe a tool set we have built. The tool set has been used to investigate the behavior of a wide range of programs. The tools are modular and can be distributed readily throughout a system.
Event Based Behavioral Abstraction (EBBA) is a high-level debugging approach which treats debugging as a process of creating models of actual behavior from the activity of the system and comparing these to models of expected system behavior. The differences between the actual and expected models are used to characterize erroneous system behavior and direct further investigation. A set of EBBA-based tools has been implemented that users can employ to construct libraries of behavior models and investigate the behavior of an errorful system through these models. EBBA evolves naturally as a cooperative distributed program that can take better advantage of computational power available in a network computer system to enhance debugging tool transparency, reduce latency and uncertainty for fundamental debugging activities and accommodate diverse, heterogeneous architectures.
Die Entwicklung von Programmen, die die vorgesehene Funktion zuverlässig erfüllen, ist schwierig. Dies wird dokumentiert durch die „Softwarekrise“, von der seit Ende der 70er Jahre gesprochen wird, und durch die Tatsache, daß seit etwa dieser Zeit beim Einsatz von Rechnern die Kosten für die Software die Kosten für die Hardware übersteigen. Die neu aufgekommene Disziplin des Software-Engineering versucht, durch geeignete Methoden und Werkzeuge den gesamten Prozeß der Erstellung von Software rechnerunterstützt effektiver zu gestalten.
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : ix 1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 1. Background : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 2. Problems in developing parallel debuggers : : : : : : : : : : : : : : : : 3 1. Quantity of state information : : : : : : : : : : : : : : : : : : : : : 3 2. Nondeterminism : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 3. Architectural variation : : : : : : : : : : : : : : : : : : : : : : : : : 5 3. Related work : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 1. Program replay : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2. Visualization : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 3. Extensibility : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 4. Portability : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13 4. Goals of this research : : : : : : : : : : : : : ...
This report describes the difficulties involved in writing efficient parallel programs and describes the hardware and software support currently available for generating software that utilizes processing effectively. Historically, the processing rate of single-processor computers has increased by one order of magnitude every five years. However, this pace is slowing since electronic circuitry is coming up against physical barriers. Unfortunately, the complexity of engineering and research problems continues to require ever more processing power (far in excess of the maximum estimated 3 Gflops achievable by single-processor computers). For this reason, parallel processing architectures are receiving considerable interest, since they offer high performance more cheaply than a single-processor supercomputer, such as the Cray. Keywords: Multiprocessing, Concurrent processing, Processor evaluation tools, Parallel debugging, Fluidics, Fluerics.
Graphical views are essential for debugging parallel programs because of the large quantity of state information contained in parallel programs. Voyeur, a prototype system for creating graphical views of parallel programs, provides a cost-effective way to construct such views for any parallel programming system. We illustrate Voyeur by discussing four views created for debugging Poker programs. One is a general trace facility for any Poker program. The other three are tailored to display a specific type of algorithmic information. Each of these views has been instrumental in detecting bugs that would have been difficult to detect otherwise, yet were obvious with the views.
The complexity of parallel programming has stimulated the development of a variety of debugging tools. This survey of recent research focuses on debugger visualization systems. The effectiveness of such systems is bounded by the degree to which their representations of run-time behavior correlate with the language structures used to incorporate parallelism, as well as the logical framework adopted by the programmer. Current visualization systems are compared with the conceptual models supported by parallel languages. Attention is drawn to the fact that debuggers are tied to specific models and that this association may restrict their usefulness and acceptability.
One of the most serious problems in the development cycle of large-scale parallel programs is the lack of tools for debugging and performance analysis. We are addressing the problem on large-scale, shared-memory multiprocessors. We have developed a dynamic, fine-grain characterization of parallel program executions based on a partial order of accesses to shared objects. This characterization forms the basis for an extensible, integrated toolkit for parallel program debugging and performance analysis. Tools in the toolkit include an interactive debugger, a graphical execution browser, performance analysis packages, and a programmable interface for user queries. Using our integrated toolkit approach, programmers can interactively analyze the behavior of parallel programs in much the same way interactive debuggers and profilers are used to analyze the behavior of sequential programs.
Parallel programming is orders of magnitudes more complex than writing sequential programs. This is particularly true for programming distributed memory multiprocessor architectures based on message passing programming models. Understanding the synchronization and communication behavior of parallel programs is one of the most critical issues in programming distributed memory multiprocessors. The paper describes methods and tools for visualization and animation of the dynamic execution of parallel programs. Based on an evaluation and classification of existing visualization environments, the visualization and animation tool VISTOP (Visualization TOol for Parallel Systems) is presented as part of the integrated tool environment TOPSYS (TOols for Parallel SYStems) for programming distributed memory multiprocessors. VISTOP supports the interactive on-line visualization of message passing programs based on various views, in particular, a process graph based concurrency view for detecting synchronization and communication bugs.
To understand a parallel program's execution we must be able to analyze lots of information describing complex relationships among many processes. Various techniques have been used, from program replay to program animation, but each has limited applicability and the lack of a common foundation precludes an integrated solution. Our approach to parallel program analysis is based on a multiplicity of views of an execution. We use a synchronization trace captured during execution to construct a graph representation of the program's behavior. A user manipulates this representation to create and fine-tune visualizations using an integrated, programmable toolkit. Additional execution details can be recovered as needed using program replay to reconstruct an execution from an existing synchronization trace. We present a framework for describing views of a parallel program's execution, and an analysis methodology that relates a sequence of views to the program development cycle. We then describe our toolkit implementation and explain how users construct visualizations using the toolkit. Finally, we present an extended example to illustrate both our methodology and the power of our programmable toolkit.
MulTVision is a visualization tool that supports both performance measurement and debugging by helping a programmer see what happens
during a specific, traced execution of a program. MulTVision has two components: a debug monitor and a replay engine. A traced execution yields a log as a by-product; both the debug monitor and the replay engine use this log as input. The debug monitor produces a graphical
display showing the relationships between tasks in the traced execution. Using this display, a programmer can see bottlenecks
or other causes of poor performance. The replay engine can be used to reproduce internal program states that existed during
the traced execution. The replay engine uses a novel log protocol—the side- effect touch protocol-oriented toward programs that are mostly functional (have few side effects). Measurements show that the tracing overhead added to mostly functional programs is generally less
than the overhead already incurred for task management and touch operations. While currently limited to program executions
that create at most tens of thousands of tasks, MulTVision is already useful for an interesting class of programs.
Techniques that manipulate logical time in order to produce coherent animations of parallel program behavior despite the presence of asynchrony are presented. The techniques interpret program behavior in light of user-defined abstractions and generate animations based on a logical, rather than a physical, view of time. If this interpretation succeeds, the resulting animation is easily understood. If it fails, the programmer can be assured that the failure was not an artifact of the visualization. It is shown that these techniques can be generally applied to enhance visualizations of a variety of types of data as they are produced by parallel, MIMD (multiple instruction stream, multiple data stream) computations
Highly parallel programs are often best understood in terms of logical patterns of inter process communication. In order to debug such programs, the user must determine the extent to which the intended patterns occur during execution. To facilitate this, we have designed and implemented a pattern-oriented debugger in which abstract, user-defined communication events can be described and animated. We report here on our initial experiences with its use.
Voyeur is a prototype system that facilitates the construction of application-specific, visual views of parallel programs. These views range from textual views showing the contents of variables to graphical maps of the state of the computational domain of the program. These views have been instrumental in quickly detecting bugs that would have been difficult to detect otherwise.
Event Based Behavioral Abstraction (EBBA) is a high-level debugging approach which treats debugging as a process of creating models of actual behavior from the activity of the system and comparing these to models of expected system behavior. The differences between the actual and expected models are used to characterize erroneous system behavior and direct further investigation.
A set of EBBA-based tools has been implemented that users can employ to construct libraries of behavior models and investigate the behavior of an errorful system through these models. EBBA evolves naturally as a cooperative distributed program that can take better advantage of computational power available in a network computer system to enhance debugging tool transparency, reduce latency and uncertainty for fundamental debugging activities and accommodate diverse, heterogeneous architectures.
Designing parallel programs to maximise the utilisation of the processing power of a multiprocessor machine requires a series of performance analysis and tuning. This paper describes a performance tuning tool for message-passing parallel programs. The tool uses a logical clock approach to instrument the program for collecting performance data. Combining the advantages of relational databases and three-dimensional spreadsheets to organise the performance data, the tool provides visual assistance for analysing the program performance. Various graphical displays which help the user to fine-tune the performance of message-passing programs are discussed.
Most message passing parallel programs employ logical process topologies with regular characteristics to support their computation. Since process topologies define the relationship between processes, they present an excellent opportunity for debugging. The primary benefit is that process behaviours can be correlated, allowing expected behaviour to be abstracted and identified, and undesirable behaviour reported. However, topology support is inadequate in most message passing parallel programming environments, including the popular Message Passing Interface (MPI) and the Parallel Virtual Machine (PVM). Programmers are forced to implement topology support themselves, increasing the possibility of introducing errors.
This paper proposes a trace- and topology-based approach to parallel program debugging, driven by four distinct types of specifications. Trace specifications allow trace data from a variety of sources and message passing libraries to be interpreted in an abstract manner, and topology specifications address the lack of explicit topology knowledge, whilst also facilitating the construction of user-consistent views of the debugging activity. Loop specifications express topology-consistent patterns of expected trace events, allowing conformance testing of associated trace data, and error specifications specify undesirable event interactions, including mismatched message sizes and mismatched communication pairs. Both loop and error specifications are simplified by having knowledge of the actual topologies being debugged.
The proposed debugging framework enables a wealth of potential debugging views and techniques. Copyright
Designing a parallel program to fully utilise the processing power
of a multiprocessor machine requires a series of performance analysis
and tuning. The paper describes a performance tuning tool for message
passing parallel programs. The tool combines the advantages of
relational databases and spreadsheets to organise the performance data
and analyse the program performance through visualisation. Various
graphical displays which assist the user to fine tune the performance of
message passing programs are discussed
First Page of the Article
Although the data placement programming model frees programmers
from writing low level communication code, it also makes it harder for
them to anticipate the performance of the code they write. In
particular, the communication that is required by a given data
distribution, and its impact on performance, may not be obvious from the
program source. Many existing performance visualization systems could be
used in attempts to investigate the performance of data placement
programs; however, no published system would provide views that relate
communication activity to the abstraction that is the primary focus of
data placement programming: data distribution. The paper introduces new
high level views of HPF program behavior that show communication
activity in the context of the array distribution from which the
compiler derived the communication. With these views, programmers can
see not only when and where communication takes place, but also what
subarrays are moving between which processors by virtue of the
communication. These views provide programmers with feedback in terms of
the programming model-the programmers' frame of reference. The
programming model as the level programmers most readily comprehend, and
it is the level at which they must improve program performance by
altering data distribution. Thus, these views provide a basis for
effective tuning of data placement programs
Nondeterminism, intended or otherwise, makes debugging message
passing parallel programs a difficult task. In this paper, we present an
on-the-fly debugging tool, mdb (Message-passing DeBugger), for
debugging programs written for the PVM (Parallel Virtual Machine), that
is effective in detecting the presence of races. mdb uses a new
class of expressions, called semantic expressions, to specify races.
These expressions capture the program semantics related to a receive
operation and are used to detect unwanted races at run-time.
mdb also has the ability to invoke sequential debuggers, making
it useful in detecting errors unrelated to races as well. Replay
debugging support by mdb provides for deterministic replay of
erroneous executions. The current implementation of mdb works
for C as well as for Fortran programs
As more sophisticated tools for parallel programming become
available, programmers will inevitably want to use them together.
However, some parallel programming tools can interact with each other in
ways that make them less useful. In particular, it a mapping tool is
used to adapt a parallel program to run on relatively few processors,
the information presented by a debugger may become difficult to
interpret. The authors examine the problems that can arise when
programmers use debuggers to interpret the patterns of message traffic
in mapped parallel programs. They also suggest how to avoid these
problems and made debugging tools more useful
The main focus in debugging and monitoring program execution is
given as the notion of time. In particular, the progress of the
execution, which is interpreted as useful computation, is addressed. The
authors describe two interpretations, or views, of the causality graph
which complement each other in the display of the propagation of the
execution. The causality graph is the graph constructed from the partial
order which reflects the execution of a parallel program. Additional
processing of the causality graph is necessary in order to retrieve
these views. This additional processing is essential since the complete,
detailed display of the graph is unrealistic for programs of reasonable
size. From the causality graph two notions are extracted: the notion of
time slice and the notion of work. The definition of a unit of work and
what this notion means for the application is provided by the user, and
serves as an additional attribute of computation and resource nodes in
the graph. These nodes are used for the generation of the views
described
Although parallel programs are significantly more complex than
sequential programs the same debugging methodology, augmented with the
appropriate tools, can be used to debug parallel and sequential
programs. Experiments have shown that these tools can reduce the
debugging cycle for a parallel program dramatically. Other techniques,
such as verification and testing, can be integrated with the debugging
methodology. For example, static analysis can be used to discover
erroneous race conditions. Verification can be used to narrow the search
space for errors during monitoring and debugging. Nonetheless, debugging
remains the most widely used technique for developing correct parallel
programs
A description is given of a collection of tools that form an
implementation of event-based abstraction (EBBA), a paradigm for
high-level debugging of distributed systems. The tools are capable of
operating effectively in a heterogeneous environment containing
processors of varying design and power. Toolset users construct
libraries of behavior models and observe the behavior of the system
through the models. The toolset is a collection of components that are
collectively a distributed system for debugging distributed systems. The
components can be combined in varying ways to provide levels of
debugging service appropriate for the resources available at individual
nodes
Chitra analyzes a program execution sequence (PES) collected
during execution of a program and produces a homogeneous, semi-Markov
chain model fitting the PES. The PES represents the evolution of a
program state vector in time. Therefore Chitra analyzes the
time-dependent behavior of a program. The authors describe a set of
transforms that map a PES to a simplified PES. Because the transforms
are program-independent. Chitra can be used with any program. Chitra
provides a visualization of PESs and transforms, to allow a user to
visually guide transform selection in an effort to generate a simple yet
accurate semi-Markov chain model. The resultant chain can predict
performance at program parameters different than those used in the input
PES, and the chain structure can diagnose performance problems
Performance problems in asynchronous massively parallel programs
are often the result of unforeseen and complex asynchronous interactions
between autonomous processing elements. Then performance problems are
not inefficiencies in source code, but gaps in the algorithm designer's
understanding of a complex physical system. The analyst forms hypotheses
about the probable causes or possible improvements, and verifies these
hypotheses by modifying the program and testing it again. These
hypotheses can be formed by a variety of methods, from simple and mostly
fruitful techniques for suggesting possible source code improvements to
the difficult, indirect, and possibly futile activity of visualizing
execution. The author describes a visualization system for massively
parallel execution data and shows how drawbacks in other analysis
methods sometimes make visualization necessary despite its difficulty
Distributed-system observation is foundational to understanding and controlling distributed computations. Existing tools for distributed-system observation are constrained in the size of computation that they can observe by three fundamental problems. They lack scalable information collection, scalable data-structures for storing and querying the information collected, and scalable information-abstraction schemes. This dissertation addresses the second of these prob- lems.
It is widely acknowledged that writing parallel programs is much more complex than writing sequential programs. This is particularly true for distributed memory multiprocessor systems and message passing programming models. Graphical representations of a program execution can increase the understanding of parallel programs. The paper describes the on-line visualization and animation system VISTOP (VISualization TOol for Parallel systems) and its use of the TOPSYS distributed monitoring system. TOPSYS (TOols for Parallel SYStems) is an integrated tool environment which aims at simplifying the usage and programming of parallel systems. It consists of several interactive development tools for specification, debugging, performance analysis and visualization. VISTOP is presented after an evaluation and classification of existing visualization environments. It supports the interactive on-line visualization of message passing programs based on various views, in particular, a process graph ba...
The LERP project aims to assist the ap1000 programmer with essential monitoring and debugging tools. LERP is based on off-line analysis and replay of an event trace. A common event trace format includes both low level system events and user-defined events. In this paper we address the issues of instrumentation of ap1000 programs with minimal interference, and presentation of traced program behaviour to the user. We describe an interface to the existing display tools ParaGraph and Upshot, and a new compound event analysis tool suited to machines of the ap1000 scale. 1 Introduction The ap1000 is a pioneering member of a class of MIMD wormhole message-passing machines with many hundreds of processors (each of which is a general purpose microprocessor with significant speed and memory in its own right), connected by three communications networks. We may term this class the "kilo-processor" machines. 1 It provides significant challenges to programmers who need to develop correct and effi...
Iterator first() next() isDone() current() traverse() creates object reference ConcreteInstrument createIterator() ConcreteIterator first() next() isDone() current() traverse() Legend: inheritance Figure 6.4: Configuring instruments to enable multiple traversal policies. ment managers, and data collectors are oblivious to such details. Shielding client code from concrete details of aggregate instrument representation has obvious information hiding advantages. Moreover, it becomes possible to choose dynamically an iteration strategy that is optimized for the current query. A difficult issue to be addressed in this design is that collections of instruments may grow and shrink as objects are created and destroyed. Hence, iterators must know about these changes so as to re-adjust themselves appropriately and to avoid race conditions when accessing instrument data. The prototype instrumentation system addresses these concerns by treating object creation and destruction as interesting events...
ResearchGate has not been able to resolve any references for this publication.