WARPED is an optimistic parallel discrete event simulation kernel that implements the Time Warp algorithm. There are various modules in WARPED which interact closely within the simulation kernel. CommManager is one of the modules of WARPED which plays an important role, when WARPED is used on a network of workstations for simulation. CommManager performs various activities such as routing of messages to the appropriate logical process, probing for messages from different logical process, receiving messages from different logical process, and routing of the incoming events to the appropriate module in WARPED. When the logical process hands the messages to CommManager, CommManager issues MPI calls to send the message to the destination logical process. Similarly, when the logical process asks the CommManager to receive messages from other logical process, it probes for messages using the MPI library calls. If there is any message that has arrived, it issues a MPI call to receive the message and hands the message to the appropriate module in WARPED.
There are several optimizations that are incorporated into the CommManager such as message aggregation [1] and infrequent polling [9]. With TCPMPL, the CommManager must be able to use TCPMPL for inter-process communication. Application user must be able to choose the combination he wants such as message aggregation with TCPMPL or infrequent polling with MPICH. In order to accommodate these different configurations, a new object oriented communication module was designed to replace the previous version.
To accommodate different physical communication libraries, an abstract physical communication interface was designed called CommPhyInterface. This interface class has pure virtual functions corresponding to each feature of the physical communication library, the CommManager was using previously. The various features are initialization of the processes, finalization of the communication library, sending of messages, and receiving of messages. These features are defined as pure virtual functions in the interface class. For each physical communication library that the WARPED kernel wants to use, a corresponding class derived from CommPhyInterface has to be defined which will issue calls specific to a particular library. The constructor of the CommPhyInterface so that only the derived classes which represent different physical communication libraries can call the constructor. The class definition of CommPhyInterface is:
class CommPhyInterface {
:
virtual CommPhyInterface();
virtual void physicalInit(int *argc, char ***argv) = 0;
virtual void physicalFinalize() = 0;
virtual int physicalGetId() const = 0;
virtual void physicalSend(char *buffer, int size, int id) = 0;
virtual char * physicalProbeRecv() = 0;
:
CommPhyInterface();
}
To accommodate the different optimizations in the communication module, an abstract communication manager interface was designed called CommMgrInterface. The CommMgrInterace has various routines which are needed to do the various activities of the original CommManager. The CommMgrInterface class assumes that optimizations at the communication module level occurs either in sending the messages or receiving the messages. Therefore, it provides two pure virtual functions which are to be implemented in the derived class (one for each communication optimization class derived from CommMgrInterface). The constructor is made protected so that only derived classes which represent different communication module can call the constructor. The communication module should also give the physical communication library it wants to use in the constructor. The class interface of CommMgrInterface is:
class CommMgrInterface {
:
CommMgrInterface();
virtual void remoteSend(BasicMsg *msg, int id) = 0;
virtual BasicMsg * recvMPIMsg() = 0;
CommMgrInterface(int lps, CommPhyInterface * phyLib);
}
With this modification in the communication module of WARPED, different physical communication libraries can be used with different optimizations at the communication manager level.