sync::watch: Use Acquire/Release memory ordering instead of SeqCst

[uklotzde]

Motivation

SeqCst is overly restrictive.

Solution

Use Release (Sender: store / single writer) and Acquire (Receiver: load / multiple readers) memory ordering for a safe handover.

[uklotzde]

I am not sure why SeqCst has been chosen here. The code comments don't tell why. With my fairly limited knowledge about memory orderings and concurrency I am confident that Release/Acquire should be sufficient for this particular use case.

[hawkw]

I'm not particularly familiar with the watch channel internals, but my assumption is that SeqCst is used here to form a total order between the state, the ref count, and the atomics used in Notify and RwLock. If the loom tests pass after making this change, though, it's possible that such a total ordering is not actually necessary to ensure correctness.

However, I would recommend also running the sync_watch.rs benchmarks before and after this change, preferably on an ARM machine (or other architecture with weak memory ordering --- on x86, all memory operations are, essentially, implicitly Acquire/Release). While SeqCst operations have a performance cost, they can also have a performance benefit in some cases --- sometimes, a more expensive SeqCst operation is actually cheaper if it succeeds on the first try and doesn't require some operation to be retried multiple times until the state of multiple atomics becomes consistent. So, it's usually worthwhile to do some before/after benchmarking when making these kind of changes.

Thanks for the PR! I hope my comment gives you some useful context for this change! :)

[uklotzde]

While SeqCst operations have a performance cost, they can also have a performance benefit in some cases --- sometimes, a more expensive SeqCst operation is actually cheaper if it succeeds on the first try and doesn't require some operation to be retried multiple times until the state of multiple atomics becomes consistent. So, it's usually worthwhile to do some before/after benchmarking when making these kind of changes.

Thank you for these insights! I wasn't aware of these possible side effects. The version is always incremented within an exclusive lock scope. Only the CLOSED bit could be set at any time. But for the latter the timing doesn't really matter, because for the related refcount only Relaxed ordering is used. These two are only eventually consistent, even with SeqCst ordering.

Unfortunately, I don't have access to an ARM machine locally so I can't run the benchmarks myself. I am aware that on x86 the proposed change has no effect.

I barely use SeqCst myself when it is possible to separate the reader/writer roles. Not only for performance but also to explicitly document the runtime dependencies.

[hawkw]

Yeah, that all makes sense. I'm certainly not at all opposed to this change --- I was just curious about whether the benchmarks had been run. If loom likes it, I would happily approve this PR. But, it would be nice to get someone more familiar with the watch implementation to take a look.

[Darksonn]

That said, it would arguably make sense to use something stronger than relaxed for ref_count_rx. Currently this assert could fail:

// thread 1
GLOBAL_BOOL.store(true, Relaxed);
drop(receiver);

// thread 2
if sender.is_closed() {
    assert!(GLOBAL_BOOL.load(Relaxed));
}

[uklotzde]

Both the sender and all receivers could be dropped independently in any order by different threads. I can't imagine how to link the sender-side closed state (refcount) with the receiver-side closed state (version bit) when using separate atomics.

[Darksonn]

Either way, it's a separate question from what you're fixing here.

[Darksonn]

Looks good to me. Just one nit.