Next: , Previous: , Up: Why use external?   [Contents]

4.1.2 How does this translate to runtime execution?

In order to fully understand what can happen, it’s important to replay the above scenario in real-world context where time does matter. Recall that the code generated from the System required a thread-safe-shell to guarantee the single-thread-active property of the application ( This was done by using a dzn::pump to schedule events on a First In, First Out (FIFO) basis for a private thread to handle.

After the first valid passwordEntered event, the Controller is Armed. If Armed, the triggered event from the Sensor leads to the Controller starting the timer. Let’s call this point t = 0. The timer is configured to timeout after 30 seconds as specified in the behavior, so the timeout event will be scheduled by the foreign Timer thread at t = 30.

Earlier it was noted that the execution time of the second passwordEntered event is x. Say a valid password is entered just before t = 30. It is now a possibility that during the execution x, t = 30 occurs which results in a timeout event being scheduled. However, after x, the Controller is in the Armed state. If you look at the behavior of the Controller component in the Armed state, a timeout event cannot be handled and as such is implicitly illegal:

state.Armed] {
  on iController.passwordEntered(pw): {
    bool valid = iPWManager.verifyPassword(pw);
    if(valid) {
      state = State.Unarmed;
  on iSensor.triggered(): {
    state = State.Alarming;