Путаница по поводу ошибки реализации в деструкторе shared_ptr

Представьте себе код, который освобождает общий указатель:

auto tmp = &(the_ptr->a);
*tmp = 10;
the_ptr.dec_ref();

Если dec_ref () не имеет семантики «выпуска», для компилятора (или ЦП) вполне нормально перемещать вещи из перед dec_ref () в после него (например):

auto tmp = &(the_ptr->a);
the_ptr.dec_ref();
*tmp = 10;

И это небезопасно, так как dec_ref () также может быть вызван из другого потока одновременно и удалить объект. Таким образом, он должен иметь семантику «выпуска», чтобы вещи оставались там до dec_ref ().

Давайте теперь представим, что деструктор объекта выглядит так:

~object() {
    auto xxx = a;
    printf("%i\n", xxx);
}

Также мы немного модифицируем пример и получим 2 потока:

// thread 1
auto tmp = &(the_ptr->a);
*tmp = 10;
the_ptr.dec_ref();

// thread 2
the_ptr.dec_ref();

Тогда «агрегированный» код будет выглядеть так:

// thread 1
auto tmp = &(the_ptr->a);
*tmp = 10;
{ // the_ptr.dec_ref();
    if (0 == atomic_sub(...)) {
        { //~object()
            auto xxx = a;
            printf("%i\n", xxx);
        }
    }
}

// thread 2
{ // the_ptr.dec_ref();
    if (0 == atomic_sub(...)) {
        { //~object()
            auto xxx = a;
            printf("%i\n", xxx);
        }
    }
}

Однако, если у нас есть только семантика выпуска для atomic_sub (), этот код можно оптимизировать таким образом:

// thread 2
auto xxx = the_ptr->a; // "auto xxx = a;" from destructor moved here
{ // the_ptr.dec_ref();
    if (0 == atomic_sub(...)) {
        { //~object()
            printf("%i\n", xxx);
        }
    }
}

Но в этом случае деструктор не всегда будет печатать последнее значение «a» (этот код больше не является свободным от гонки). Вот почему нам также нужна семантика получения для atomic_sub (или, строго говоря, нам нужен барьер получения, когда счетчик становится 0 после декремента).

Это запоздалый ответ.

Начнем с этого простого типа:

struct foo
{
    ~foo() { std::cout << value; }
    int value;
};

И мы будем использовать этот тип в shared_ptr следующим образом:

void runs_in_separate_thread(std::shared_ptr<foo> my_ptr)
{
    my_ptr->value = 5;
    my_ptr.reset();
}

int main()
{
    std::shared_ptr<foo> my_ptr(new foo);
    std::async(std::launch::async, runs_in_separate_thread, my_ptr);
    my_ptr.reset();
}

Два потока будут работать параллельно, и оба будут владеть объектом foo.

При правильной реализации shared_ptr (т. Е. Реализации с memory_order_acq_rel) эта программа имеет определенное поведение. Единственное значение, которое напечатает эта программа, - 5.

При неправильной реализации (с использованием memory_order_relaxed) таких гарантий нет. Поведение не определено, поскольку введена гонка данных foo::value. Проблема возникает только в тех случаях, когда деструктор вызывается в основном потоке. При ослабленном порядке памяти запись в foo::value в другом потоке может не распространяться на деструктор в основном потоке. Может быть напечатано значение, отличное от 5.

Так что же такое гонка за данными? Что ж, ознакомьтесь с определением и обратите внимание на последний пункт:

Когда оценка выражения записывается в ячейку памяти, а другая оценка считывает или изменяет ту же ячейку памяти, говорят, что выражения конфликтуют. Программа, имеющая две конфликтующие оценки, имеет гонку данных, если только одна из них

• обе конфликтующие оценки являются атомарными операциями (см. std :: atomic)
• одна из конфликтующих оценок происходит раньше другой (см. std :: memory_order)

В нашей программе один поток будет писать в foo::value, а один поток будет читать из foo::value. Предполагается, что они будут последовательными; запись в foo::value всегда должна происходить до чтения. Интуитивно понятно, что они будут такими, поскольку деструктор должен быть последним, что происходит с объектом.

memory_order_relaxed не предоставляет таких гарантий заказа, поэтому memory_order_acq_rel является обязательным.

В разговоре Херб показывает memory_order_release, а не memory_order_relaxed, но расслабиться было бы еще больше проблем.

Если delete control_block_ptr не обращается к control_block_ptr->refs (что, вероятно, не имеет), тогда атомарная операция не несет зависимости от удаления. Операция удаления может не затрагивать какую-либо память в блоке управления, она может просто вернуть этот указатель в распределитель freestore.

Но я не уверен, говорит ли Херб о том, что компилятор перемещает удаление перед атомарной операцией, или просто ссылается на то, когда побочные эффекты становятся видимыми для других потоков.

Похоже, он говорит о синхронизации действий над самим разделяемым объектом, которые не показаны в его блоках кода (и как результат - сбивают с толку).

Поэтому поставил acq_rel - ведь все действия над объектом должны произойти до его уничтожения, все по порядку.

Но я все еще не уверен, почему он говорит о замене delete на fetch_sub.