Какое снижение производительности у слабого_птр?

Question

В настоящее время я разрабатываю объектную структуру для игры, и самой естественной организацией в моем случае стало дерево. Будучи большим поклонником умных указателей, я использую исключительно shared_ptr. Однако в этом случае дочерние элементы в дереве будут нуждаться в доступе к его родителю (например, существа на карте должны иметь возможность доступа к картографическим данным - следовательно, данные своих родителей.

Направление владения, разумеется, состоит в том, что карте принадлежат ее существа, поэтому они имеют общие указатели на них. Однако для доступа к картографическим данным внутри существа нам необходим указатель на родителя - умный способ указателя - использовать ссылку, т.е. weak_ptr.

Тем не менее, я однажды прочитал, что блокировка weak_ptr - это дорогостоящая операция, может быть, это уже не так, но, учитывая, что weak_ptr будет блокироваться очень часто, я обеспокоен тем, что эта конструкция обречена на низкая производительность.

Отсюда вопрос:

Какое снижение производительности при блокировке слабого_птр? Насколько это важно?

Answer 1

Из исходного кода Boost 1.42 (<boost/shared_ptr/weak_ptr.hpp> строка 155):

shared_ptr<T> lock() const // never throws
{
    return shared_ptr<element_type>( *this, boost::detail::sp_nothrow_tag() );
}

ergo, комментарий Джеймса Макнеллиса верен; это стоимость копирования shared_ptr.

Answer 2

для моего собственного проекта, я смог значительно улучшить производительность, добавив #define BOOST_DISABLE_THREADS перед включением любого повышения. Это позволяет избежать издержек спин-блокировки / мьютекса в файлеуги_слабого_приятия, который в моем проекте был главное узкое место. Поскольку проект не является многопоточным по сравнению с бустом, я мог бы сделать это.