Какое снижение производительности для weak_ptr?

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

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

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

Следовательно, вопрос:

Какова эффективность блокировки функции weak_ptr? Насколько это важно?

Ответ 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, комментарий Джеймса Макнеллиса правильный; это стоимость копирования-построения a shared_ptr.

Ответ 2

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