Attention is currently required from: fixeria, laforge, 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 2:

(1 comment)

Patchset:

PS2:

And for the case at hand, I still belive it makes much more sense to simply use an osmo_itq to pass […]

I'm in a bit of a communication dilemma:

- laforge says don't use any mutexes and just directly write to rate_ctr from the other thread. - pespin says use an osmo_it_q here - pespin says use intermediate storage with mutexes in a comment at https://gerrit.osmocom.org/c/osmo-hnbgw/+/36385 - nhofmeyr says directly write to rate_ctr, but still have a mutex around stats reporting, so that counter pairs are always in sync.

I interpret it so that laforge is radically "bare-metal" and simple, pespin radically thread-safe and elaborate, and i'm actually in the middle, a little more to laforge's side.

Yet it seems you guys are missing the actual point for this patch here: A mutex lock around stats reporting is a very basic and very powerful tool. It allows a multi-threaded application to decide which stats updates will always be in sync.

This patch adds this feature, in a completely optional way. It is up to the application how to make use of it, so let's discuss those details at the other patches.

I fail to see any problem with this patch and don't know how we can reach a consensus on this. Neither of us seems to accept the others' arguments. At least I still think that I'm right...