Attention is currently required from: pespin.

View Change

1 comment:

• File library/Mutex.ttcn:

  • Patch Set #2, 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"];
    }
    ```

To view, visit change 38206. To unsubscribe, or for help writing mail filters, visit settings.