The DAQV-II [5] framework for program interoperability provides external tools with a view of distributed data as a logical global array that can be accessed selectively via a high-level array reference; see Figure 1.
Each application process is linked with a DAQV library that provides a simple procedural interface allowing the programmer to describe how data is distributed and to indicate places in the code where it may be accessed. The library creates a slave thread that shadows execution of the application process. The purpose of these threads is to maintain information about available distributed data and to perform accesses to that data when requested. The reason for embodying this functionality in the form of a thread is so that querying the information and accessing the data can be done concurrently with the execution of the application processes, if desired. DAQV-II uses the threading system provided by the Nexus multithreaded communication library [2] to create and manage these slave threads.
The individual slave threads are coordinated by a separate process called the DAQV master. The master process is also responsible for interacting with the other tools and applications in the DAQV environment by acting as the ``single point of contact'' for the entire set of application processes. The master process spawns additional threads to handle the various requests it receives; because it also uses Nexus, the master process is fully multithreaded and can take advantage of multiple processors, if available.
External tools, also known as DAQV clients, use a client interface that implements a high-level array access model. From the point of view of a tool, the interface gives access to arrays registered by the application. The client interface runs as a separate thread in the tool process and is responsible for communicating requests to and receiving events from the master, and participating in data communication. A detailed description of the operation of array access can be found in [7].
DAQV-II was originally designed to allow external tools to access distributed application data. For example, a visualization tool could use DAQV-II to access arbitrary subsections of the global array created by each of the declared program array instances in the multiple processes of a parallel program. Each process registers its portion of the global array with DAQV; the DAQV master process coordinates these registrations and interprets them in a global context. At points indicated in the program source code, interactions with external tools (via the DAQV master) are allowed. It is the reponsibility of the application programmer to ensure that access is provided at scientifically and semantically meaningful points in the code.
DAQV-II was designed to support both synchronous and asynchronous (with respect to application execution) data access. Synchronous data access is fairly straightforward and uses a debugger-like model whereby application execution is suspended while data access occurs. Asynchronous access, however, requires a separate thread of control to carry out data access while the application continues execution. Our initial implementation provides synchronous access to program data because accessing this type of data asynchronously is prone to consistency problems (i.e., an executing application is free to modify its program data without concern for what other threads may be doing).
However, accessing program performance data that is being collected and stored by a separate profiling library demands a low-impact, performance-efficient monitoring technique if that data is to be made available to external tools. The profiling library goes to great lengths to minimize perturbation; requesting and transporting that data to an external tool should, too.
