[french]Version française

Schooner's Presentation

[Objectives] [Programming model]

1. Objectives

 Schooner (which means Sloop Communication Library for High-level, Object-Oriented, aNd Efficient Remote Exchanges) is a library of classes used for writing parallel and distributed applications in C++. Its main purposes are:
  1. to be independent of the used communication protocol,
  2. to give the user a structured and abstract view of its application (farm of available computers, set of computation nodes),
  3. to allow a straightforward redefinition of its behaviours. Advantages using an object-oriented language are mainly modularity and reusability: for example, it is straightforward to add a new message type or to change the application scalability.
Its low level defines a minimal set of mechanisms that must be provided for either coarse or fine grained concurrent applications development (mainly computation entities definition and data exchange primitives among them). Thanks to inheritance mechanisms, this set can straightforwardly be redefined and enlarged. Moreover, this set definition is such that the user can get a structured and abstract view of its application support (farm of available computers, set of computation entities supports, ...). Data exchanges between computation entities is achieved by an active message mechanism - due to the generality and easy-to-use of this communication model.

This set of mechanisms can be implemented using the appropriate subset of any C library for communication and distributed computation supports. Indeed, interfacing any of those libraries (PVM, TPVM, Nexus, PM2 for example) those mechanisms are either directly available or can be easily emulated. For instance, a PVM-based Schooner implementation would - solely - call the pvm_addhost(), pvm_spawn(), pvm_send(), pvm_receive() functions.

Schooner is presently used as a run-time support for:

[Back to top]

2. The programming model

The classes that build up the Schooner library can be split into three layers, depending upon the level of functionality they provide :
  1. the first layer consists of an interface to any communication library and, if needed, to any thread library;
  2. the second layer is built up of classes that allow the user to create computation nodes also called clusters; these clusters can interact thanks to active messages;
  3. a third layer enables to program communicating objects which also can interact via active messages. If needed, any communicating object can be bound to a thread and as such be active.
layer
The following figure gives a run-time example of an application built upon Schooner.
runtime

2.1 Clusters and computers

Cluster

A cluster can be thought of as an entity which designs a context (memory, CPU, ...) on a computer. We can also find this notion in other libraries: environment process of Pt-PVM, context in Nexus, modules in PM2.

In most cases, a cluster will be mapped on one Unix process, but we can also choose to group several or all clusters of the application on a same Unix process. In this way, it is very straightforward to change the scalability of the application.

Computer

The location for a new Cluster is represented by a Computer. We can choose to select a specific computer, the ``best computer'', or a randomized one. The definition of a computer requires three informations: a symbolic name, the real name of the computer (network name or IP address) and its architecture.

Many computers with different symbolic names can be associated to the same physical machine. The use of symbolic name allows to define a virtual architecture which can be mapped on different configurations.

Schooner provides one trivial implementation of the ``best computer'' function. But any Schooner user could derive and rewrite it using application related informations and also load measures that could be obtained by external tools (like for example DLB - which is under development in the SLOOP team - whose aim is to dynamically provide load informations of a multi-users NOWs).

2.2 Active messages

The model for inter-cluster communications is based on an active message mechanism. Active messages allows to extend the message-passing model to a single-sided operation. Once a message is received on a cluster, a processing function dependent of the received message type is automatically triggered.

An active message object is an instance of a class which publicly inherits (directly or indirectly) from the Message class. This class defines the following member functions:

  1. flat(...) which is used to flatten an object Message in order to send it via the communication network,
  2. rebuild(...) which is used to rebuild an object Message,
  3. process(...) which specifies the processing to perform when an object of class Message is received on a cluster.

2.3 Communicating objects

A - possible - third layer of Schooner offers a communicating objects model. The behaviour of such objects resembles the one of clusters, in the sense that they interact through active messages sending. Their main purpose is to enable a finer granularity computation and so, 1 or many communicating objects can be mapped on a cluster. By a straightforward derivation and implementation of the communicating object class, Schooner also provide active communicating objects.

[Back to top]

Back to Schooner homepage
Contact
Last modified: Mon Mar 2 15:26:37 MET