fNetworkActive is not protected by a lock, use an atomic #9131

pull jonasschnelli wants to merge 1 commits into bitcoin:master from jonasschnelli:2016/11/net_toggle changing 1 files +1 −1
  1. jonasschnelli commented at 1:11 PM on November 11, 2016: contributor

    Reported by @sipa: #8996 (review)

  2. fNetworkActive is not protected by a lock, use an atomic 079142b757
  3. jonasschnelli added the label P2P on Nov 11, 2016
  4. luke-jr commented at 1:14 AM on November 12, 2016: member

    Is this enough? Does bool actually behave differently as an atomic if we don't use the atomic-specific functions? I would think using .exchange() would be necessary to ensure the logic is itself atomic as well.

  5. sipa commented at 1:45 AM on November 12, 2016: member

    @luke-jr Yes. An assignment to an std::atomic results in a fully sequentially serialized behaviour. You can use .store(value, memory_order_relaxed) for example if you want weaker consistency (but still atomic) behaviour.

  6. sipa commented at 1:46 AM on November 12, 2016: member

    @theuni Can you comment here? You probably understand CConnman's threading model best.

  7. theuni commented at 9:47 PM on November 12, 2016: member

    Sure, making it atomic should solve the problem at hand. @sipa I avoided commenting on the network active PR because IMO the model needs to change a bit to make it completely safe. I have some of those changes queued up, but I didn't want to stand in the way of the feature. For now, let's just make this atomic.

    Ultimately, CConnman::Start and CConnman::Stop need to be used for network activation. They were designed to function that way, it's just not complete yet. The idea is that the network threads stop when the toggle is set, which would guarantee that p2p is really down. What's missing is the ability to bring it back up with the same config.

  8. rebroad commented at 3:33 AM on November 13, 2016: contributor

    Slightly OT, but when is it best to use locks vs atomics?

  9. sipa commented at 5:03 AM on November 13, 2016: member

    @rebroad Whenever you can use atomics, atomics. They are many times faster than locks.

  10. sipa commented at 10:45 PM on November 15, 2016: member

    utACK 079142b75771c5b39a76a1eaa6347bce5e99c0b3

  11. laanwj commented at 9:09 AM on November 16, 2016: member

    utACK https://github.com/bitcoin/bitcoin/commit/079142b75771c5b39a76a1eaa6347bce5e99c0b3

    Slightly OT, but when is it best to use locks vs atomics?

    This is not the first time that a question you ask is just a google search away. There is literally tons of CS literature about synchronization primitives. In any case atomic access 'protects' only one variable, whereas locks can protect multiple from concurrent access. As there is nothing else that needs to remain internally consistent at the same time as fNetworkActive changes, an atomic will do.

  12. laanwj merged this on Nov 16, 2016
  13. laanwj closed this on Nov 16, 2016

  14. laanwj referenced this in commit 62af164638 on Nov 16, 2016
  15. luke-jr referenced this in commit ea2d47c6d5 on Dec 21, 2016
  16. codablock referenced this in commit 0932079ea6 on Jan 15, 2018
  17. andvgal referenced this in commit 9df012418d on Jan 6, 2019
  18. CryptoCentric referenced this in commit 528c7da783 on Feb 24, 2019
  19. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-21 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me