fNetworkActive is not protected by a lock, use an atomic

[jonasschnelli]

Reported by @sipa: #8996 (comment)

[paveljanik]

ACK 079142b

[luke-jr]

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.

[sipa]

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

[sipa]

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

[theuni]

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.

[rebroad]

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

[sipa]

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

[sipa]

utACK 079142b

[laanwj]

utACK 079142b

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.