Design of Converse

After determining the necessity of handling the different models of concurrency and control regimes in single-threaded modules, message-driven objects, and thread-based modules, the following guidelines were used in the design of Converse:

Completeness of coverage: The interoperability framework should be able to efficiently support most approaches, languages and frameworks for parallel programming. More concretely, any language or library that can be portably implemented on MIMD computers should be able to run on top of Converse and interoperate with other languages.

Efficiency: There should not be any undue overheads for (a) remote operations such as messages, and (b) local scheduling such as the scheduling of ready threads, as compared to the cost of such operations in a native implementations.

Need based cost: The Converse framework must support a variety of features. However, each language or paradigm should incur only the cost for the features it uses. For example, an application that requires sophisticated dynamic load balancing might link in a more complex load balancing strategy with its concomitant overhead, while another application may link in a very simple and efficient load balancing strategy.

An important observation that influenced the design of Converse is the fact that threads and message-driven objects need a scheduler, and a single unified scheduler can be used to serve the needs of both. Apart from the central scheduler, the other components of Converse are: A machine interface (CMI), Thread objects, and load balancers, as shown in Figure 2.2. When initialized, a language runtime registers one or more message-processing functions (called handlers) with Converse. These language-specific handlers implement the specific actions they must take on receipt of messages from remote or local entities. The language handlers may send messages to remote handlers using the CMI, or enqueue messages in the scheduler's queue, to be delivered to local handlers in accordance with their priority. The Converse scheduler is based on a notion of schedulable entities, called ``generalized messages''.

Figure 2.2: Software Architecture of Converse