Check out the new USENIX Web site. next up previous
Next: Some Predicates Revisited Up: DISCUSSION Previous: Event Semantics

Messaging Policy

  In our current implementation, a thread is waiting for message arrivals at each gate. By default, messages are processed in an FIFO order. It is sometimes useful to change this order for example according to the role of the sender, the content or the logic time of the message, etc.

We can easily specify the messaging policies. The on-arrival rules defined at each gate can insert the arrived messages to a central queue maintained in the database. An (infinite) loop there can activate various event handlers which process messages in the queue. The following is only one way to implement a messaging policy, where implementation of the underlined predicates are left to the user. These two predicates are policy-dependent.
\begin{smalltab}
\={\bf on-take} \= :-\\ \\ gt \\ gt{\bf add} queue([]),\\ \\ gt...
 ...(G, Msg)),\\ \\ gt \\ gt{\bf post-event}$^{sync}$(execution-loop).\end{smalltab}
Timer events and user-posted events can also be processed through the queue. To do this, the built-in post-event predicates must be overridden to insert the events into the queue. But care must be taken so that the post-event predicates used above still work as intended.

This scheme has significant advantages. First, the need for concurrency control inside the cocavm is ameliorated, since at any moment there is only one rule active in a cocavm. We can maintain a central event queue, which includes all message arrivals, timer or user-posted events, instead of a pure message queue. Second, it is easier to stop the execution of the current rule set say when the participant wants to switch to a different role or a different policy (rule set) at runtime[19]. When the command to freeze the runtime state is received, each cocavm can simply neglect messages with logical time later than that of the freeze command.

This design assumes that predicates in event handlers can finish within a reasonable time. When a blocking predicate is called, it is still feasible to specify a sophisticated threads scheduling policy to suspend the waiting thread and continue to process another event. But if a predicate takes too long or loops forever, however, all the other events must suffer even indefinitely, as such situations are hard to detect mechanically.


next up previous
Next: Some Predicates Revisited Up: DISCUSSION Previous: Event Semantics
Du Li
8/25/1999