2.5 Asynchronous Communication and Synchronous Communication

Asynchronous communication and synchronous communication are the two different types of inter-model communication. They define the semantics of sending and receiving messages via ports, after necessary connections are established.

Asynchronous sending means sending without waiting for response. DCharts require that an action be provided to send messages asynchronously to a specified port. A message, as discussed in section 2.2.7, is a tuple $<MN,\gamma>$ where $MN$ is its name, and $\gamma$ is a set of parameters. The message is buffered and the action returns immediately.

In many cases, the sender is not interested in when or whether a message is received by the receiver. However, mechanisms (possibly in the constraint language) should be provided to check this result. There are two possible mechanisms:

1. Checking function. It is a boolean function that returns whether a message has been received. A model may use this function in the actions or guards to check the status of a message sent previously.

2. Callback. A certain event is sent by the simulation/execution environment of the sender when the confirmation from the message receiver is received by the sender. The event name is specified by the sender model at the time when it sends out the message. The parameters of a callback event is implementation-dependent.

Synchronous sending means sending a message and waiting until the receiver confirms the receipt of the message with an acknowledgment. Some communication protocols allow to test whether a message is correctly received, or to wait until it is received. A DCharts implementation on such a protocol may not require acknowledgments.

Since a model is simulated or executed sequentially, synchronous sending blocks the whole model until the simulation/execution environment knows the message is received. During the blocking period, all the incoming events are queued by the simulation/execution environment. Some scheduled transitions may be delayed because of this blocking. As a result, if a model uses synchronous sending, it is the designer's responsibility to make sure that the time constraints of scheduled transitions (if any) are satisfied. (Event scheduling and timing of DCharts models are discussed in chapter 3.)

The following algorithms use the facilities of asynchronous sending to simulate synchronous sending:

1. If a checking function is provided, the model asynchronously sends a message, and goes to an isolated state. A transition is repeatedly scheduled after a certain period (timeout). When this transition is triggered, it checks the status of the message in its guard. If the checking function returns $true$, the model goes back to the previous state; otherwise, the same transition is scheduled after the same timeout period.

2. If callback is supported, the model asynchronously sends a message, and goes to an isolated state. The callback event triggers a transition from that state back to the previous state.

In both cases, the isolated state must accept all other events and sequentially record them in a variable. At the time when the model goes back to the original state, those recorded events are re-broadcast in the same order. This explicitly models part of the global event list of the simulator/executor.