Подтвердить что ты не робот

Почему libС++-реализация shared_ptr использует полные барьеры памяти вместо расслабления?

В ускоряющей реализации shared_ptr он использует расслабленное упорядочение памяти, чтобы увеличить счетчик ссылок. Это выглядит безопасным, поскольку декреты используют метод получения/освобождения, чтобы убедиться, что все предыдущие сокращения видны в потоке перед выпуском памяти. Этот метод кажется правильным и появляется в Herb Sutters говорить об атоматике

В реализации libС++ используются полные барьеры памяти

template <class T>
inline T
increment(T& t) _NOEXCEPT
{
    return __sync_add_and_fetch(&t, 1);
}

template <class T>
inline T
decrement(T& t) _NOEXCEPT
{
    return __sync_add_and_fetch(&t, -1);
}

}  // name

Есть ли причина для этого решения? Существуют ли различия в производительности или безопасности между ними?

4b9b3361

Ответ 1

Потому что, когда я написал этот код, компилятор (clang) еще не реализовал атомарность С++ 11. И я никогда не возвращался к нему, чтобы очистить его.

Здесь нет ничего тонкого.: -)