Почему эти безблокировочные реализации подсчета ссылок не взрываются (или взрываются)?

Я пытаюсь разобраться в алгоритмах LFRC, но продолжаю находить примеры, в которых я предполагаю, что они работают, но не могу понять, почему. Я сосредоточен на копировании и удалении. В частности, есть три, которые следуют одному и тому же общему шаблону (псевдокод):

Copy {
  shared = source->shared;
  if (shared != null) {
     Atomically_Increment_Counter(shared);
  }
}

Delete {
  if (shared != null) {
     oldcounter = Atomically_Decrement_Counter(shared);
     if (oldcounter == value signifying all references released) {
        Deallocate(shared);
     }
  }
}

Первый из статьи Lock-Free Reference Counting Дэвида Л. Детлефса, рисунок 2, страница 8 (отредактировано для форматирования):

void LFRCCopy(SNode **v, SNode *w) {
   Snode *oldv = *v;
   if (w != null) 
      add_to_rc(w,1);
   *v = w;
   LFRCDestroy(oldv);
}

void LFRCDestroy(SNode *v) {
   if (v != null && add_to_rc(v, -1)==1) {
     LFRCDestroy(v->L);
     LFRCDestroy(v->R);
     delete v;
   }
}

Где add_to_rc — атомарное приращение и нагрузка. Второй — из реализации Mat в opencv4 (отредактировано для краткости):

// Line 405
Mat::Mat(const Mat& m)
    : flags(m.flags), dims(m.dims), rows(m.rows), cols(m.cols), data(m.data),
      datastart(m.datastart), dataend(m.dataend), datalimit(m.datalimit), allocator(m.allocator),
      u(m.u), size(&rows), step(0)
{
    if ( u )
        CV_XADD(&u->refcount, 1);
    ...
}

// Line 551
void Mat::release()
{
    if ( u && CV_XADD(&u->refcount, -1) == 1 )
        deallocate();
    u = NULL;
    ...
}

Где CV_XADD — атомарное приращение и нагрузка. И третий — из реализации std::shared_ptr, которая поставляется с libstdc++ в самой последней версии GCC (10.2) (эта реализация очень сложная, и я сильно ее отредактировал для краткости):

class _Sp_counted_base {

    void _M_add_ref_copy()
    { __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }

    // Line 161 for full implementation
    void _M_release() noexcept
    {
       _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_use_count);
       if (__gnu_cxx::__exchange_and_add_dispatch(&_M_use_count, -1) == 1)
       {
          _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_use_count);
          _M_dispose();
          if (_Mutex_base<_Lp>::_S_need_barriers)
             __atomic_thread_fence (__ATOMIC_ACQ_REL);
          // editors note: weak pointer handling removed for brevity
          _M_destroy();
       }
    }

}

class __shared_count {

    __shared_count(const __shared_count& __r) noexcept 
        : _M_pi(__r._M_pi)
    {
        if (_M_pi != nullptr)
           _M_pi->_M_add_ref_copy();
    }
    
    ~__shared_count() noexcept
    {
        if (_M_pi != nullptr)
           _M_pi->_M_release();
    }

    _Sp_counted_base* _M_pi;

}

class __shared_ptr {

    __shared_ptr(const __shared_ptr&) noexcept = default;

    ~__shared_ptr() = default;

    element_type*   _M_ptr;         // Contained pointer.
    __shared_count  _M_refcount;    // Reference counter.

}

Некоторое объяснение последнего, поскольку оно косвенное:

• Копирование: __shared_ptr конструктор копирования по умолчанию копирует _M_refcount, чей конструктор копирования использует тот же _Sp_counted_base, что и оригинал, и атомарно увеличивает счетчик ссылок.
• Удалить: __shared_ptr деструктор по умолчанию уничтожает _M_refcount, чей деструктор вызывает _M_release для _Sp_counted_base, что атомарно уменьшает и, возможно, освобождает счетчик ссылок.

В любом случае, все это сводится к одному вопросу, который является сутью моей неспособности понять, почему они работают (даже эта старая статья доктора Доббса и связанные с ней вопросы здесь, на SO [я чувствую, что ответ может быть здесь но я его не вижу] вызвало у меня больше вопросов, чем ответов):

В операции копирования, что предотвращает состояние гонки, когда другой поток выполняет операцию удаления последнего счетчика ссылок (возможно, через другое представление общего объекта), а затем освобождает объект между началом операции копирования и началом атомарного приращение счетчика - таким образом, из того, что я (неправильно) понимаю, заставляя копию увеличивать освобожденный счетчик и аварийно завершать работу или сбрасывать ядро ​​везде или что-то в этом роде?

То есть, ссылаясь на вышеприведенную реализацию opencv (поскольку именно с ее изучения начался весь мой мини-исследовательский проект здесь):

Mat::Mat(const Mat& m)
    : flags(m.flags), dims(m.dims), rows(m.rows), cols(m.cols), data(m.data),
      datastart(m.datastart), dataend(m.dataend), datalimit(m.datalimit), allocator(m.allocator),
      u(m.u),   // <--- START OF DANGER ZONE 
      size(&rows), step(0)
{
    if ( u )     
                // <--- ALMOST AT END OF DANGER ZONE 
        CV_XADD(&u->refcount, 1);
    ...
}

void Mat::release()
{
    if ( u && CV_XADD(&u->refcount, -1) == 1 )
        deallocate();
    u = NULL;
    ...
}

Что удерживает другой поток от выпуска последней ссылки через m в помеченной «опасной зоне» в конструкторе копирования, таким образом оставляя u не нулевым, но указывающим на мусор после освобождения?

Что мне здесь не хватает? Я чувствую, что это может быть очевидно, и, возможно, я слишком долго не спал. В частности, тот факт, что реализация libstdc++, похоже, также следует этому шаблону, придает ей массу уличного доверия; Я просто не могу понять подробности.