3.3 Declaring Event Messages and Posers

Currently, event messages are declared with no reference to what they might inherit from (unlike in Charm++). The translator takes care of this. In addition, they must define operator=.

 
class myMessage {
public:
int someData;
myMessage& operator=(const myMessage& obj) {
eventMsg::operator=(obj);
someData = obj.someData;
return *this;
}
};

Similarly, posers do not refer to a base class when they are declared. Posers are required to have a void constructor declared that simply initializes the data to sensible values. A destructor must be provided as well. In addition, a pup and operator= must be provided. The pup method should call the pup method of the global state representation class being used.

 
class mySim {
int anInt; float aFloat; char aString[20];
 public:
mySim();
mySim(myMessage *m);
~mySim();
void pup(PUP::er &p);
mySim& operator=(const mySim& obj);
void myEventMethod(eventMsg *m);
void myEventMethod_anti(eventMsg *m);
void myEventMethod_commit(eventMsg *m);
...
};

Further, for each event method, a commit method should be declared, and if the synchronization strategy being used is optimistic or involves any sort of rollback, an anti-method should also be provided. The syntax of these declarations is shown above. Their usage and implementation will be described next.

November 07, 2009
POSE Homepage
Charm Homepage