Attention is currently required from: fixeria, laforge, pespin.

View Change

1 comment:

• Patchset:

  • Patch Set #2:

    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...

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