Зачем «удалять» узлы в этом стековом классе без блокировки может привести к состоянию гонки?

Question

В книге под названием «C++ параллелизм в действии» Энтони Уильямс, в разделе 7.2.1, реализация стека безблокировочного находится в списке:

template <typename T> 
class lock_free_stack { 
    struct node { 
     shared_ptr<T> data_; 
     node* next_; 
     node(const T& data) : data_(make_shared(data)) {} 
    }; 
    atomic<node*> head_; 
public: 
    void push(const T& data) 
    { 
     node* new_node = new node(data); 
     new_node->next_ = head_.load(); 
     while(!head.compare_exchange_weak(new_node->next_, new_node)); 
    } 
    shared_ptr<T> pop() 
    { 
     node* old_head = head_.load(); 
     while (old_head && 
       !head_.compare_exchange_weak(old_head, head_->next_)); 
     return old_head ? old_head->data_ : shared_ptr<T>(); 
    } 
}; 

Затем в разделе 7.2.2, автор говорит». .. в pop() мы выбрали утечку узлов, чтобы избежать условия гонки, когда один поток удаляет узел, в то время как другой поток по-прежнему содержит указатель на него, что он вот-вот разыгрывает ».

1) Я не понимаю, почему такой сценарий может произойти и почему функция следующего попа() может вызвать состояние гонки:

shared_ptr<T> pop() 
{ 
    node* old_head = head_.load(); // (1) 
    while (old_head && 
      !head_.compare_exchange_weak(old_head, head_->next_)); // (2) 
    shared_ptr<T> res; // (3) 
    if (old_head) { 
     res.swap(old_head->data); 
     delete old_head; 
     return res; 
    } else { 
     return {}; 
    } 
} 

2) Как приходит, что для нескольких потоков, которые называют поп() в то же время переменная «old_head» может указывать на тот же объект объекта после строки (3)?

Answer 1

Резьба 1 переходит к (2). Он начинает оценивать head_->next. Он загружает head_ в регистр, а затем отдает приоритет.

Резьба 2 исходит от начала до конца функции. Он удаляет head_ из существования, удаляя его и возвращает содержимое head_.

Нить 1 просыпается. Он следует head_ в регистре, получающем поле ->next. Но нить 2 уже удалила данные, на которые указывает head_, и мы просто следовали за висячим указателем.