Inside STL: Waiting for a std::atomic to change, part 2 -- Raymond Chen

Last time,┬áwe looked at how the Microsoft C++ standard library implements┬áwait┬áand┬ánotify_*┬áfor┬ástd::atomic<std::shared_ptr<T>>. Today, weΓÇÖll look at the other library that (as of this writing) implements┬ástd::atomic<std::shared_ptr<T>>: libstdc++.

Inside STL: Waiting for a std::atomic<std::shared_ptr<T>> to change, part 2

by Raymond Chen

From the article:

The first thing to note is that the traditional ΓÇ£wait for a value to changeΓÇ¥ mechanism on unix is the futex, but futexes (futexen?) are limited to 4-byte values, which is insufficient for a 64-bit pointer, much less the┬átwo┬ápointers inside a┬áshared_ptr.

At this point, I will refer you to learn about┬áhow libstdc++ implements waits on atomic values, particularly the section on┬áhow it handles types that do not fit in a┬á__platform_wait_t. The remainder of this discussion will treat that as an already-solved problem and focus on the shared pointer part.

Okay, back to┬áatomic<shared_ptr<T>>::wait():

// atomic<shared_ptr<T>>::wait
void
wait(value_type __old,
     memory_order __o = memory_order_seq_cst) const noexcept
{
    _M_impl.wait(std::move(__old), __o);
}

When you wait on a┬áshared_ptr, the work is done by┬á_Sp_atomic::wait:

// _Sp_atomic<shared_ptr<T>>::wait
void
wait(value_type __old, memory_order __o) const noexcept
{
    auto __pi = _M_refcount.lock(memory_order_acquire);
    if (_M_ptr == __old._M_ptr && __pi == __old._M_refcount._M_pi)
      _M_refcount._M_wait_unlock(__o);
    else
      _M_refcount.unlock(memory_order_relaxed);
}

View the full article