Given a reference count decrement such as the following:

void release_and_maybe_deallocate(std::atomic<int>& count, foo* data)
{
    if (count.fetch_sub(1, std::memory_order_acq_rel) == 1)
    {
        delete data;
    }
}

It’s usually given as common knowledge that while the increment can use std::memory_order_relaxed (because the reference count must already be at least 1 because the reference count must’ve been acquired from somewhere else that was already holding a reference when it became visible to the current thread), while the decrement has to be both an acquire and a release operation. My question is why exactly the acquire part is nessecary, at least during the decrement.

I would imagine that the above could also written as:

void release_and_maybe_deallocate(std::atomic<int>& count, foo* data)
{
    if (count.fetch_sub(1, std::memory_order_release) == 1)
    {
        std::atomic_thread_fence(std::memory_order_acquire);
        delete data;
    }
}

Which would save a fence on the “happy” path that someone else is still holding a reference. My first thought as to why this might not work was that potentially an acquire might be needed because the sub needs to synchronise with all the previous increments, but I don’t think that’s correct, because the increments are all relaxed, so there’s no garantee that any increments could be visible on the other thread. In other words, this series of events might happen:

1. Thread A creates a refcount with value 1
2. Thread A publishes a pointer to the refcount and makes it visible with value 1 to Thread B
3. Thread B does a relaxed increment on the refcount, which isn’t made visible to Thread A
4. Thread A decrements the refcount, but because the increment above hasn’t yet been released, it still appears as 1 after an acquire and therefore Thread A deallocates the memory
5. Thread B accesses the memory and causes a bug

So I would assume that the act of accessing the memory to decrement it is somehow sufficent to observe the relaxed increments on thread B, otherwise the above may happen and even acq_rel wouldn’t be sufficent for decrementing the refcount.

Another reason I thought of might be because we would want to avoid writes which happen after the decrement to avoid moving behind the decrement, but I’m also uncertain about that because surely any of those writes would have to be known to be to be to an address not being deallocated if the branch is taken, otherwise the program would still be wrong in a single threaded context (accesses which would be incorrect if the branch would be taken would happening before the branch, which obviously can happen in hardware but would be invalidated by the branch misprediction and never become visible to other threads)

I get that a release is nessecary to make sure that when the memory is deallocated the changes to the data from the current thread are visible to the deallocating thread (since the changes may effect the behaviour of the destructor) and that an acquire is nessecary on the deallocating thread to receive those changes, but I can’t think of a reason why the acquire is nessecary on the path where the memory isn’t deallocated.

Is moving the acquire to a fence only on the branch where the memory is deallocated still correct and combining the acquire and release into the increment just an arbitrary choice that everyone made? Or is there some aspect of the memory model I’ve misunderstood that makes the acquire nessecary before the decrement? Or perhaps there’s something about having the acquire be on a fence instead of an instruction that makes it either incorrect or has too much of a performance penalty when the branch is taken, although I don’t think the differences between an instruction acquire vs a fence acquire (which I know are slightly different) are that harsh