Объркване относно грешка при внедряване в деструктора shared_ptr

Представете си код, който освобождава споделен указател:

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

Ако dec_ref() няма семантика за "освобождаване", е напълно добре за компилатор (или CPU) да премести нещата от преди 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.