Attention is currently required from: pespin.

fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email )

Change subject: library: add generic Mutex API for parallel components ......................................................................

Patch Set 2:

(1 comment)

File library/Mutex.ttcn:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/d67cec94_c356c... : PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */

What's the point in having 2 ports instead of 1? Sounds way more complex than it should by doing so, […]

The point is that multiple parallel components are sending `MUTEX_LOCK` requests and they're getting queued. When the `f_MutexDisp_main()` handles one of those requests, it expects to receive `MUTEX_UNLOCK`, which (if we were to use a single port) will end up somewhere in the queue (behind `MUTEX_LOCK` requests from other components). TTCN-3 does not allow to look up inside the queue, so I had to use two ports: one for locking and the other for unlocking.

Below is a mscgen graph visually explaining the problem, which can be rendered by https://mscgen.js.org/ for instance:

``` msc{ ConnHdlrA, ConnHdlrB, ConnHdlrC, MutexDisp;

ConnHdlrB => MutexDisp [label="MUTEX_LOCK.req"]; ConnHdlrA => MutexDisp [label="MUTEX_LOCK.req"]; ConnHdlrC => MutexDisp [label="MUTEX_LOCK.req"];

ConnHdlrA box MutexDisp [label="ConnHdlrB was quicker, so it gets the mutex first"];

ConnHdlrB <= MutexDisp [label="MUTEX_LOCK.cnf"]; ...; ConnHdlrB => MutexDisp [label="MUTEX_UNLOCK.ind"];

ConnHdlrA box MutexDisp [label="MutexDisp still has two MUTEX_LOCK.req in the queue and the MUTEX_UNLOCK.ind is not on top"]; } ```