Attention is currently required from: fixeria.
pespin 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/83343dd3_1683… :
PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */
> Ah ok so you are using the port queue based on the the sender to decide/filter whether to operate/wa […]
Ah no erase what I said above. The mutex you are implementing here is no reentrant.
If a component calls LOCK operation twice, it will deadlock/timeout.
By implementing it they way I mention you then get a reentrant Mutex.
But I guess your implementation is good enough for what we need here for now.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 13:41:25 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin 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/a508af9d_a43d… :
PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */
> The point is that multiple parallel components are sending `MUTEX_LOCK` requests and they're getting […]
Ah ok so you are using the port queue based on the the sender to decide/filter whether to operate/wait for the lock operator.
I'd have done that with 1 port and then maintaining a queue of vc_conn lock operations internally in the component, but fine your way too then.
Waiting for feedback to Harald's comment to provide +1.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 13:37:26 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
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_c356… :
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"];
}
```
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Id71f43bd5fc78d4bb4417d6c01fcff8112ea6032
Gerrit-Change-Number: 38206
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 20 Sep 2024 12:58:02 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
osmith has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ci/+/38226?usp=email )
Change subject: jobs/gerrit: use deps cache from docker image
......................................................................
jobs/gerrit: use deps cache from docker image
Instead of freshly cloning the dependencies each time, use the cache we
already have in the debian-bookworm-titan docker image. This way only
the dependency repositories that were changed in the patch submitted to
gerrit need to be updated.
Related: OS#6572
Change-Id: I895011edf49f612d0df7f4759dc374bab60c32a6
---
M jobs/gerrit-verifications.yml
1 file changed, 6 insertions(+), 0 deletions(-)
Approvals:
pespin: Looks good to me, but someone else must approve
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/jobs/gerrit-verifications.yml b/jobs/gerrit-verifications.yml
index 58752cd..f98eac9 100644
--- a/jobs/gerrit-verifications.yml
+++ b/jobs/gerrit-verifications.yml
@@ -444,6 +444,12 @@
{timeout_cmd} \
sh -e -x -c '
useradd --uid=1000 build
+ chown -R build:build /osmo-ttcn3-hacks/deps
+ for i in /osmo-ttcn3-hacks/deps/*/; do
+ if ! [ -e /build/deps/"$(basename "$i")" ]; then
+ ln -s "$i" /build/deps/
+ fi
+ done
su build -c "make -C /build compile"
'
pipeline_binpkgs: ""
--
To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/38226?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: merged
Gerrit-Project: osmo-ci
Gerrit-Branch: master
Gerrit-Change-Id: I895011edf49f612d0df7f4759dc374bab60c32a6
Gerrit-Change-Number: 38226
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>