Deadlock in System

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

Severity

for JUnit testcases.

for other system blocks.

In some cases, the situation indicates that you don't intend further behavior. For example, there is no further behavior after displaying the result of an action with operation “display”. For this case, you can either ignore the warning or add an activity final node after the operation.

In other cases, the warning indicates that some behavior never gets executed (see the example below). For this case, you may need to revise your system specification.

JUnit testcases should always terminate to assure execution of all testcases when running many at a time.

Possible Action(s)

For JUnit testcases you will have to fix this error.

For all other system blocks this situation leads only to a warning. Thus, you do not necessarily 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.

Example

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

The contract of inner block Inner is shown below.

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

As depicted in (1), both inner blocks Inner are in the initial state. An activity step that includes two initial nodes and pin start of both the inner blocks is taken. Due to the step, now both inner blocks are in state s0 as also depicted in (2).

As depicted by the contract of the inner block, an inner block is now waiting event via pin in or stop. Following the upstream flow from pin in and stop of the left hand-side block Inner, we find that a token from pin out of the right hand-side block is needed. This case never happens since the right hand-side block is also waiting an event via its pin in or pin stop. Pin in is connected to pin out of the left hand-side block, while pin stop requires a former event via its own pin out. Therefore, deadlock!