Deadlock in Local Block

This type of issue applies for local blocks. It indicates that the block stays forever in a state which is not a final state. No further progress is possible since no more activity step can be taken.


This warning is an indication that some behavior never gets executed as you intended. You can use the animation tool to check the complete behavior of your block.

Possible Action(s)

This situation is not an error. Thus, you do not required to change your block specification. However, it is a good idea to check the behavior of your block with the animation tool. There might be behavior that you did not intend.


An example of this type of situation is depicted in the following figure.

Using the animator that can show the sequence of activity steps taken towards the deadlock situation we get four figures depicted below.

As depicted in (1), initially block Request Handler and inner block Flow Director are in the initial state. An activity step that includes node req, operation request, the fork node, and perceptions READY and MESSAGE are taken.

In (2), we see each perception holds a token because of the previous activity step. Moreover, block Request Handler is now in state active (see the contract of this block in the first figure of this page, lower right hand-side part). An activity step that includes perception READY and the join node is taken.

In (3), we see that due to the previous step, the left hand-side edge of the join node holds token. An activity step that includes perception MESSAGE, pin in, pin out1, operation display and pin change is taken. As shown in the contract of inner block Flow Director (see the first figure of this page, upper right hand-side part), this step corresponds to the transition labelled with in/out1; change. Thus, the inner block is in state to_out2 as also depicted in (4). Now, there is no other activity step that can be triggered and, therefore, block Request Handler will stay forever in state active (deadlock).