std::shared_ptrКакие из методов std::shared_ptr из нового стандарта C++11 потокобезопасны и что подразумевается под "многопоточный вариант shared_ptr" и "озаботившись указать для shared_ptr быстрый pool-аллокатор"?
http://habrahabr.ru/post/131478/#comment_4365579

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

автор1. Это слишком медленно в языках, где ВСЕ является ссылкой (аналог С++ — все обернуто в shared_ptr). На С++ так пишут только неадекватные товарищи типа некоторых лисперов).
2. Инкремент и декремент счетчика быстрые, пока приложение однопоточное. Основные тормоза дают new — выделение памяти в куче, и delete во время равенства ссылки нулю.
3. Это важный момент — не сам подсчет ссылок тормозит, а аллокатор.
4. Наиболее частая операция для умного указателя — разыменование — такая же по скорости, как для тупого.

Так что тормоза сделать можно только весьма искусственно — оборачивать все в многопоточный вариант shared_ptr, и это все постоянно создавать и уничтожать, не озаботившись указать для shared_ptr быстрый pool-аллокатор.
На самом деле все утвеждения кроме п.4 высосаны из пальца.

1. Нет никаких причин по умолчанию не использовать shared_ptr (при совместном владении) или unique_ptr (при одном владельце). Наоборот, скорее неадекватны те кто используют raw-указатель когда доступны умные - это отказ от бесплатной потоко- и исключение-безопасности.

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

3. Использовать make_shared (а не какой-то там пул, реализацию которого еще найти надо на всех платформах)

Итого - при правильном использовании никаких тормозов из-за shared_ptr нет.

sherzod_например при передаче в какую-либо многопоточную очередь важно быстрое копирование разделяемого указателя, многопоточный вариант будет работать намного медленнее при том что очередь уже сама организует безопасную вставку, извлечение.
Многопоточный подсчет ссылок внутри shared_ptr нужен независимо от блокировки контейнера.
Например если один поток вставил в очередь, а другой прочитал, то мы имеет 2 копии указателя.
Теперь если оба потока удалят свою копию, то счетчик ссылок должен атомарно отработать, т.к. удаление копий уже не защищено блокировкой очереди.

std::shared_ptrAnatoly MoskovskyНо по умолчанию - многопоточность shared_ptr включена.
И в std тоже включена по умолчанию? А как отключить её в std?

Зачем?

Т.е. по умолчанию безопасно удаление, чтение, разыменовывание и копирование из общего между потоками экземпляра shared_ptr.
С чего вы взяли что это безопасно?
Для общего экземпляра безопасно только чтение (включая разыменовывание и копирование).
Если же хотя бы один поток может присваивать или удалять объект в общем экземпляре указателя, то тогда воообще все операции включая чтение должны быть защищены внешним мьютексом.

std::shared_ptrAnatoly MoskovskyНо по умолчанию - многопоточность shared_ptr включена.
И в std тоже включена по умолчанию? А как отключить её в std?

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

std::shared_ptrAnatoly MoskovskyНа всех современных платформах есть lock-free инкременты, которые вносят несущественный оверхед, чтобы заботиться об отключении в однопоточном случае.
Но это же в любом случае кэш пинг-понг, а именно из-за него не стали добавлять shared_mutex в std, т.к. именно из-за него по мнению авторов boost:thread разделяемый мьютекс медленней обычного мьютекса даже на операциях чтения. Т.е. они посчитали lock-free менее производительным чем обычный мьютекс.
Не может быть просто мютекс быстрее чем шаред мьютек из-за локфри, потому что и там и там переключение мьютекса производится одной и той же атомарной операцией. По другому просто нельзя сделать.

Это я к чему.
Сели две группы людей: одни криворукие написали тормознутую реализацию shared_mutex, другие слепые не смогли там разглядеть что тормозит и не включили в стандарт потому что подумали что те криворукие самые умные и быстрее сделать нельзя.
А между тем была еще одна группа, которая в Windows Vista реализовала свой shared_mutex (под названием slim read/write lock), который размером всего в один указатель, и работает быстрее чем boost::mutex. А там простой юзермод локфри - тот который якобы медленнее мьютекса.

std::shared_ptr,

Я ж уже написал. Разница в скорости между бустовскими mutex и shared_mutex не из-за так называемого пингпонга (который есть в обоих случаях), а из-за громоздкой, нафарширванной ненужными фичами реализации shared_mutex.
Вот бенчмарки: http://askldjd.wordpress.com/2011/03/06/performance-comparison-on-reader-writer-locks/

Возвращаясь к счетчику ссылок.
Если взять голый атомарный счетчик, то он безусловно быстрее простого счетчика защищенного любым видом мьютекса.
Что тут еще обсуждать?

sherzod_По моему в том обсуждении выражалась немного другая мысль. Простая мысль о том что как ни крути, shared_mutex будет намного намного медленнее при выполнении как ни парадоксально именно задачи для него предназначенной, и именно из-за интенсивного обмена кэш-линиями между ядрами.
Намного медленнее чего ? Просто мьютекса?
Обычный мьютекс имеет те же самые проблемы что и шаред.
Точно так же при каждом захвате и освобождениии мьютекса происходят обновления кешей ядер.
Говорить о том что шаред мьютекс принципиально медленнее обычного - нонсенс.

sherzod_Anatoly MoskovskyНамного медленнее чего ? Просто мьютекса?
Обычный мьютекс имеет те же самые проблемы что и шаред.
Точно так же при каждом захвате и освобождениии мьютекса происходят обновления кешей ядер.
Говорить о том что шаред мьютекс принципиально медленнее обычного - нонсенс.
Анатолий, попробуйте смоделировать ситуацию о которой говориться в обсуждении. А именно ситуацию когда есть много мелких параллельных чтений одного и того же ресурса (скажем разделяемой памяти или порта). Чтение этой памяти будет последовательным, что в сущности выстроит все потоки в очередь.

Память защищенная шаредмьютексом редко меняется и часто читается (иначе это неверное использование такого мьютекса).
Поэтому в кеше каждого ядра будет находиться локальная копия данных, и соответственно все рассуждения про последовательный доступ к внешней памяти при чтении данных - неверны.

Кроме того, что вам не понятно в том бенчмарке что я выше привел?
Там же ясно показано, что бустовский шаредмьютекс существенно медленнее чем виндовый.
Не говоря уже о том что если при чтении ресурса хоть какая-то нетривиальная обработка происходит и время блокировки достаточно велико, то даже бустовский шаредмьютекс сразу бьет обычный мьютекс.

Если же опять вернуться к счетчику ссылок от которого вы постоянно куда-то в сторону уводите, то как я уже выше объяснял в типичном многопоточном приложении кол-во копий смартуказателя в разных потоках в среднем 1 и не превышает 2. А в однопоточном - ровно 1. И поэтому все рассуждения что зашита счетчика мьютексом быстрее чем просто атомарный инкремент (напомню в среднем без конкурирующих потоков) - нонсенс. С мьютексом будет две записи во внешнюю память+оверхед на обработку состояния мьютекса (в частности условный переход который может приводить к сбою предсказания переходов), а с атомарным инкрементом - просто одна безусловная запись, которая от обычного неатомарного инкремента отличается всего лишь парой дополнительных циклов на блокировку шины.
Поэтому возвращаясь к тому с чего началось - отключать многопоточность подсчета ссылок в shared_ptr нет смысла.

sherzod_Ваше утверждение что при длительной операции чтения boost::shared_mutex быстрее boost::mutex тоже безосновательно. Хотелось увидеть разбор причин, почему он должен быть быстрее.

Это же элементарно. Шаред лок это как следует из названия блокировка которую одновременно могут держать несколько потоков при чтении ресурса. Обратите внимание что допустим 100 потоков, при чтении за 10 сек каждый, суммарно выполнят чтение за те же 10 сек + тот постоянный оверхед про который вы тут все время говорите. Чем больше время удержания блокировки тем несущественнее вклад этого оверхеда (который кстати такой же как и у обычного мьютекса, о чем я многократно уже говорил)
А в точно такой же ситуации с уникальным локом - все потоки справятся за 100*10 секунд. Причем большую часть этого времени все эти потоки будут проводить в ожидании.

В этом и заключается назначение шаред мьютекса - избежать ожидания там где в нем смысла нет.

Ваше предположение о том что читаемая память будет в кэше не совсем верное. А если верное то это именно тот случай когда не следует применять shared_mutex. Мы ведь рассматриваем сценарий много читающих, мало или один записывающий. Без лишних объяснений думаю уже поймете что в таком сценарии нужно предотвратить кеширование читаемого/записываемого ресурса (volatile?). Зачем много раз читать то что не изменилось?
Мы каждый раз читаем потому что не знаем изменилось или нет.
Но в большинстве случаев данные не изменяются и остаются в кеше.

std::shared_ptr1. А почему в boost/std не сделали элементарнейшую обертку над Win slim read/write lock и POSIX pthread_rwlock_t? Может оставили на следующий стандарт :)
2. slim read/write lock - это именно локфри или вейтфри? То что вы говорите, атомарный CAS захват счетчика - это вейтфри.
1. Наверно когда делали это в бусте, в винде еще не было этого мьютекса (он есть начиная с Висты).
Почему не приняли в стандарт хотя бы концептуально, не знаю. При том что вполне часто встречаются кейсы для применения именно совместной блокировки (см. мой предыдущий ответ).

2. Ну если логически рассуждать то вряд ли объект реализующий концепцию блокировки можно назвать lock-free :) Ну и не wait-free тоже естественно. Под slim там подразумевалось что все реализуется атомарными операциями в usermode (а не в ядре). Хотя часто именно это имеют в виду когда говорят lock-free.

std::shared_ptr,

Это все терминология, у которой нет устоявшегося смысла.
Например если взять вот эти определения то никак wait-free не выходит, т.к. нет никаких гарантий по времени на выполнение совместной блокировки.