#9 Simulator can deadlock when receiving port not ready

[Anders Carlsson]

In a network where
- an actor sends tokens to its own input port(s)
- the input buffer size is limited
The simulator may deadlock, supposedly because it does not verify that the receiving port(s) is ready for more tokens before firing an action that will write to it.

[Anders Carlsson]

Clarification: the simulator will deadlock despite existence of an action that will drain the blocking input port.

[Jorn W. Janneck]

Interesting. I suppose the reason is that an actor locks down completely until the backpressure is removed.

A possible solution would be to only lock actions that write to output ports that get backpressure, but we need to make sure this does not unlock actions that would be locked otherwise because of priorities. If A > B and A is locked because of backpressure but B is not, then we should not fire B if otherwise all preconditions of A are fulfilled (i.e. if A could be fired in an unbounded model). Doing otherwise would mean that action sequences (and therefore actor behavior) would be affected in unpredictable ways by changing buffer sizes.

Note: The CLR actually contains a passage that explicitly makes the presence of output space part of the firability criterion. This should be changed for the above reason.

Consider this example:

actor Route () A ==> X, Y:
P: action [a] ==> X: [a]
guard a > 0 end
NP: action [a] ==> Y: [a] end

priority P > NP; end
end

Clearly, we would intend this actor to send the positive input tokens to X and all the others to Y, which it does in an unbounded model. If we would start to only disable the first action when the X output fills up, then suddenly the second action would become firable for all input tokens.

So I suppose we need to handle action selection slightly differently in order to not stall an actor unnecessarily when only some of its outputs fill up.