Краткое введение: я работаю над многопоточным кодом, и мне приходится разделять динамически выделяемые объекты между двумя потоками. Чтобы сделать мой код более чистым (и менее подверженным ошибкам), я хочу явно «удалять» объекты в каждом потоке, и поэтому я хочу использовать shared_ptr.
Первый вопрос:
Я хочу знать, есть ли у реализации -> operator в shared_ptr дополнительные накладные расходы (например, больше, чем unique_ptr) во время выполнения. Объекты, о которых я говорю, обычно представляют собой долгоживущие экземпляры, копируемые только один раз после создания (когда я распределяю их между потоками), тогда я обращаюсь только к методам и полям этих объектов.
Я знаю, что shared_ptr защищают только подсчет ссылок.
Второй вопрос:
Насколько хорошо shared_ptr оптимизированы в libstdc ++? Всегда ли он использует мьютекс или использует преимущества атомарных операций (я сосредотачиваюсь на платформах x86 и ARM)?
shared_ptrпри разыменовании указателя через->не должно быть никаких накладных расходов. Я не знаком с libstdc ++, поэтому не могу ответить на ваш второй вопрос. Однако у вас есть заголовки, поэтому вы можете легко узнать, взглянув на то, как это реализовано. - person James McNellis schedule 05.06.2012std::atomic<int>или что-то подобное для счетчика ссылок; Является ли это настоящим аппаратным (безблокировочным) атомарным, зависит от версии компилятора - я считаю, что это было улучшено в GCC 4.7.0. - person Kerrek SB schedule 05.06.2012operator->выглядит точно так же, как и старый добрыйauto_ptr, т.е. можно ожидать нулевых накладных расходов. - person Damon schedule 05.06.2012shared_ptrи много версий GCC и libstdc ++. О каком вы говорите? - person Nicol Bolas schedule 05.06.2012