Hermes: a language for distributed computing
Hermes: a language for distributed computing
Introduction to OSF DCE (rev. 1.0)
Introduction to OSF DCE (rev. 1.0)
ABC++: concurrency by inheritance in C++
IBM Systems Journal
Monitors: an operating system structuring concept
Communications of the ACM
CASCON '94 Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research
Integrating real-time and partial-order information in event-data displays
CASCON '94 Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research
The use of process clustering in distributed-system event displays
CASCON '93 Proceedings of the 1993 conference of the Centre for Advanced Studies on Collaborative research: software engineering - Volume 1
Single stepping in event-visualization tools
CASCON '96 Proceedings of the 1996 conference of the Centre for Advanced Studies on Collaborative research
A Tool for Debugging OSF DCE Applications
COMPSAC '96 Proceedings of the 20th Conference on Computer Software and Applications
Hi-index | 0.00 |
A process-time diagram showing the execution history of individual processes and the interactions between processes can be a very useful tool in understanding the behaviour of a distributed or concurrent application. Because of the variety of environments for writing distributed and concurrent applications, a tool that produces such diagrams is most useful if it is not tied to a particular environment. This paper [1] describes techniques that can be used to obtain such target-environment independence. Because target environments can differ in their conceptual model of process interactions, e.g., message passing versus remote-method invocation, it is important to provide a very general structure for such specifications, making as few assumptions as possible about characteristics that must be possessed by all target environments. By making reference to our experience with the implementation of the Partial-Order Event Tracer, we will suggest principles for effectively using table-driven implementations and appropriate means for dealing with odd situations that cannot reasonably be coded into a table or control file. We claim that appropriate use of such techniques need not compromise execution effciency, relative to a tool designed for only one environment, and also allows easy implementation for a new target environment.