Attention is currently required from: pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36538?usp=email )
Change subject: add osmo_stats_report_lock api ......................................................................
Patch Set 1:
(4 comments)
Patchset:
PS1:
I think with this you are only sorting out one of the concurrency problems when using rate_ctr/stats […]
How the caller chooses to use this remains very specialized for an application, the main aim is to allow a hook to mutex around the stats reporting.
The way this is used in my hnbgw patch: The main thread simply also holds a osmo_stats_report_lock() while groups are added/removed. Because the counter-retrieving thread acquires osmo_stats_report_lock() when updating counters, things are guarded.
File src/core/stats.c:
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/4578fe90_562cc039 PS1, Line 808: pthread_mutex_destroy(g_report_lock);
What happens if a pthread_mutex is destroyed while used? […]
good point
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/37dcc5d3_51ee4c81 PS1, Line 819: void osmo_stats_report_lock(bool lock)
I'd definetly have 2 APIs here, one for lock and one for unlock. […]
easier to trace: good point
https://gerrit.osmocom.org/c/libosmocore/+/36538/comment/ada84510_dddd3e86 PS1, Line 831: pthread_mutex_t *lock = g_report_lock;
what's the point of this local variable?
brevity; but in fact looks like leftovers from evolution of the patch, thx
-
neels