Is memory_order_acquire on reference counted pointers to trivially destructible types superfluous?

Question

This question is specifically about trivially destructible types within reference counted pointers. See the example from Boost's documentation on uses of atomics.

The decrement is as follows:

if (x->refcount_.fetch_sub(1, boost::memory_order_release) == 1) {
  // A
  boost::atomic_thread_fence(boost::memory_order_acquire);
  delete x;
}

1. We know that, due to memory_order_release, all reads/writes of x are completed before the fetch_sub (see here). Thus, if we happen to reach point A then all uses of x are complete.

2. At point A in the code, we are not guaranteed by the standard to see the latest value of x until after the memory_order_acquire fence...

So here is my question regarding the second statement about memory_order_acquire:

When x points to a trivially destructible type (for example, int where x is int * const) is the memory_order_acquire pointless? The rationale I have is because if x is trivially destructible then the latest changes to x does no affect the deletion of x?

For example, whether the deleting thread's delete x; sees the latest x such that *x = 10 or an outdated value such that *x = 8 the destruction process is always the same regardless (as long as the pointer x itself remains constant). It knows that no one is going to modify the x from that point thanks to the release and so all it has to do is deallocate.

Is there another benefit of memory_order_acquire that I am missing here? Is my thinking correct and if not then why do we need to see the latest value of x on the deleting thread?

Answer 1

The standard is not written in terms of which interleavings of operations in racing threads might happen. I gather such a specification would be too strict: compilers need to reorder loads and stores, even across sync points, for speed.

Instead, the standard simply says what a data race is, and that they're undefined behavior.

Informally, a data race occurs when:

• one thread accesses memory;
• another thread writes to the same memory location; and
• there's no synchronization between the two threads to impose an order on the two accesses.

Deleting an object counts as a write, even if the destructor is trivial. If two threads access *x and then decref it using your code, and one thread deletes x, we can see that all three requirements are fulfilled. There is a data race on *x.

The data race isn't on x->refcount_, since both threads access it with an atomic operation (an explicit exception, in the standard, to the sloppy definition of "data race" I gave above). But because the memory ordering is release on both threads, it doesn't synchronize the two threads.

---

People often try to imagine what compiler shenanigans might lead to actual misbehavior in practice, to see if the race might be considered "benign", but I've given up on this. According to the standard, the lack of a release-acquire handoff makes the behavior undefined.

Answer 2

No way!

You seem to believe that barriers are a tool to be able to

• publish a data structure in a thread, typically with a release/store on an atomic pointer (analog of volatile reference in Java)
• check that the publication occurred (load the atomic pointer and check the value) and read the data (load/acquire)

But that's just one example of the use of atomics and barriers.

In general barriers associated with relaxed atomic operation make mutual exclusion well defined. A mutex is a mutual exclusion device, a null then non null atomic pointer is another, and a reference count is yet another.

A reference count functions like a RW lock, with:

• RC increment = R lock
• RC decrement = R unlock
• observing (RC = 0) after a decrement = W lock

The (RC=0) observation is the analog of lock operation because it must have mutual exclusion with the property (RC>0). Mutual exclusion translates to a release-acquire pair, for each series of computations that need exclusion. All the users of the data controlled by the RC device need mutual exclusion with the memory release (not mutex release) operation.

Answer 3

Let's consider the following example:

Initialization

int * const x = new int{42};
std::atomic<int> refcount = 2;

Thread A and Thread B

assert(*x == 42);
if (refcount.fetch_sub(1, std::memory_order_release) == 1) {
  // std::atomic_thread_fence(std::memory_order_acquire);
  delete x;
}

In that example the assert could fail or worse since it could access already destroyed and deallocated object. The problem is that there is no happens before relationship between accessing *x in one thread and its deletion in another. The assert can get reordered after the decrement of refcount in the same thread even when memory_order_release is employed.

To form this happens before relationship we need a synchronization point between threads, and release-acquire does exactly that. That is why we need an acquire fence before deleting *x. Alternatively we could use memory_order_acq_rel instead of memory_order_release when decrementing refcount and that would be enough as well.