Most traditional messaging libraries (such as MPI) are composed of global functions. This can be a awkward if different messaging layers exist. For example, if you have a bunch of processes connected by a high speed network and by a low speed network, there is no obvious way to specify which you want to use in any given case.
To get around this problem with the Cheetah library we introduce the idea of a controller. Unlike an MPI communicator, which is a parameter passed to the global functions and is little more than a way to specify different spaces of message tags, the communication functions of Cheetah are member functions of a controller. Multiple controllers can exist at one time and they can be nested. This provides a deeper level of sophistication in messaging layers than is feasible with just global functions.
Controllers are constructed with a letter-envelope or Bridge pattern. That is, there is a user-visible class called Controller that consists solely of a (reference counted) pointer to an implementation base class. Subclasses of the base class implement specific kinds of controllers, such as shared memory, MPI, User Level Messaging, etc. The interface class defers all of its member functions to the implementation class.
The deferred member functions are:
Each of these member functions (except ncontexts and mycontext) of Controller has a corresponding abstract virtual member function in ControllerImpl, and they must be implemented by the specific subclass.
The routines ncontexts and mycontext are not virtual, and instead return values stored in ControllerImpl. The idea here is that the subclass will store the appropriate values there if and when there is a change in the contexts. This implementation style is used to ensure that calling ncontexts and mycontext is fast in all implementations.