pthread?

std::thread

и чем оно лучше остальных? я не против, просто хочется получить развёрнутый ответ.

тот же вопрос, что и выше. ну понятно, изкоробочность, а ещё?

Кроссплатформенность наверное

threads cannot be implemented as a library.pdf

zthread.pdf

Какая библиотека для обеспечения многопоточности в С++ лучшая, на ваш взгляд?

Qt.

хочется получить развёрнутый ответ.

Знакома лучше всех, не мало практики с ней, кроссплатформенно.

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

хоть и зи

Инкрементирую.

Qt

std::thread, Qt, POCO. Ты лучше критерии лучшести огласи

Что есть лучше?

Я пользовался и Qt, и boost, и std, и pthread. Все они хорошие. Такты не считал.

Позволю себе добавить, что выбор Qt решает не только проблему с использованием потоков, но и добавляет к ней отличнейшее средство межпоточного взаимодействия в виде сигналов/слотов.

tbb

std::thread ибо стандарт (в C++11 еще и лямбды умеет), очень удобно сделан класс QThread в Qt. Если нужен параллелизм, то можно взглянуть на C++ Actor Framework (CAF), сложно и монструозно, но работает.

Всё зависит от задачи, где-то и OpenMP будет достаточно.

Использовал livev в одном из своих проектов. Показал себя просто отлично. А вообще для многопоточности сейчас лучше go заюзать. Я так и сделаю как только в проекте понадобиться.

отличнейшее средство межпоточного взаимодействия в виде сигналов/слотов.

facepalm

Товарищ дело говорит. Сабж потокобезопасен, если грамотно использовать, можно очень хороших результатов добиться.

Ещё шикарные контейнеры, шикарные классы для ввода-вывода, отличные инструменты для гуйни и прочее, прочее, прочее... Qt вообще шибко подсаживает.

Qt

Кстати, что там не так? Как оно работает? Разве это не засахареный способо регистрировать коллбеки? Я не использую, но вот любопытно

Подробности будут или это просто очередной виток газификации малых водохранилищ?

Контейнеры с copy-on-write вообще замечательны и намного удобнее в работе, чем контейнеры из std::

Ну и все остальное тоже очень даже кул.

Ну ты как всегда.

Я вот тоже прям дождаться не могу, когда он уже начнёт жечь глаголом...

Кстати, что там не так? Как оно работает? Разве это не засахареный способо регистрировать коллбеки?

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

Сабж потокобезопасен, если грамотно использовать, можно очень хороших результатов добиться.

Если «грамотно использовать», то добиться результатов можно везде. А потокобезопасность сомнительна, т.к. данные всё равно как-то приходится шарить между потоками.

Не помешала бы иммутабельная паранойя

Не помешала бы иммутабельная паранойя

И GC, чего уж там. Чтобы данные проживали время передачи сообщения (shared_ptr не предлагать).

Использование с/с как IPC...

Ууу, всё ясно. Ваше мнение самое важное для нас!

А потокобезопасность сомнительна, т.к. данные всё равно как-то приходится шарить между потоками.

У Qt половина тулкита потокобезопасна это раз. Передавать данные между потоками бывает требуется только на чтение это два. Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три. Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может. ЗЫ сломать можно всё и в одном потоке, делаем queued соединение, шлём указатель на объект в стеке, ловим веселый сегфолт, это таки кресты, жабофилам и прочим сеньёрам такое не осилить.

И GC, чего уж там.

Ну если мозгов осилить работу с памятью не хватает (а что там сложного я никак не пойму) без GC никак, будет тупить, пердеть, жрать память аки «не в себя» но ворочаться как и вообще всё написанное на всяких ваших жабах...

protothreads

Что ж тебя так забаттхертило-то?

У Qt половина тулкита потокобезопасна это раз.

Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили. Спасла тебя потокобезопасность вектора? в С++11 весь STL в плане const методов потокобезопасен - и чо?

Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три.

За этой отмазкой прячется всегда говнодизайн. Тупые программисты в проекте всегда будут и не всегда их код будет нормально ревьюится. Твое мнение диванного теоретика про идеальный случай оставь себе. Дизайн приложения не должен позволять легко ошибиться, даже ламеру. Иначе это говнодизайн.

Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может.

От этого факта в вакууме ни холодно ни жарко.

ЗЫ сломать можно всё и в одном потоке, делаем queued соединение, шлём указатель на объект в стеке, ловим веселый сегфолт, это таки кресты, жабофилам и прочим сеньёрам такое не осилить.

Аргумент на уровне детсада. «А я могу себе х@й прострелить!»

Ну если мозгов осилить работу с памятью не хватает (а что там сложного я никак не пойму)

Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.

в основном из-за потери контекста сообщения за время доставки

1. Положить конекст на стек

2. Стек переключать

3. ....

4. PROFIT

И GC, чего уж там. Чтобы данные проживали время передачи сообщения (shared_ptr не предлагать).

Аналогично моему предыдущему комментарию.

Не совсем понял идею. Переключать стек для чего? Чем эти «стеки» будут отличаться от кучи?

Что ж тебя так забаттхертило-то?

Забатхёртило твои влажные фантазии, у меня тут полный порядок.

Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили.

Не умеешь работать с памятью, убери свои кривые лапки от крестов жабофил!

За этой отмазкой прячется всегда говнодизайн. Тупые программисты в проекте всегда будут и не всегда их код будет нормально ревьюится. ... Дизайн приложения не должен позволять легко ошибиться, даже ламеру. Иначе это говнодизайн.

С кодом должны работать профессионалы, а иначе что не городи будет всё плохо. Хороший дизайн позволяет исключить некоторый возможный геморрой, обеспечить быстрое и лёгкое включение в разработку, разбить разработку на части, модифицировать и поддерживать минимальными трудозатратами и не должен содержать не очевидных «подводных камней».

Твое мнение диванного теоретика про идеальный случай оставь себе.

Сказал профессор, не знающий даже что такое IPC! :D

От этого факта в вакууме ни холодно ни жарко.

Это позволяет сократить кол-во кода и естественным путем делает его более наглядным.

Аргумент на уровне детсада. «А я могу себе х@й прострелить!»

На твой «х подстрелить» и отвечено как противовес. Сути ты не ловишь, твои самострелы делаются и в одном потоке, особенность ЯП такая. Тут мозг применять надо, а не аки Обама с гранатой по клаве молотить...

Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.

Ничего подобного, большинство ошибок правда очепятки и синтаксические, иногда по запаре и что похуже. Но жопа у меня не болит, в отличии от. А GC не жрёт ресурсы. Я счастлив.

Лучше пиши на С#, там с потоками всё отлично.

Не умеешь работать с памятью, убери свои кривые лапки от крестов жабофил!

Мимо кассы два раза.

С кодом должны работать профессионалы

Пока, диванный теоретик. Ждем, пока ты устроишься на работу и узнаешь правду.

Мимо кассы два раза.

ЧСВ, такое ЧСВ, это было обращение к собирательному образу, (девиз, лозунг или как-то так).

Пока, диванный теоретик. Ждем, пока ты устроишься на работу и узнаешь правду.

Давай, давай, ванга-неоудачник. Устройство на работу уже давно пережитый и преодолённый этап моей жизни. По себе судить окружающих - удел неудачников и школьничков. Первым уже не поможешь, вторые бывает вырастают. Надеюсь у тебя пройдёт. ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D

Давай, съезжай на личности дальше. Я достаточно натрахался с быдлокодом любителей сигналов в другие потоки, чтобы не считать 1. мир идеальным, а разработчиков поголовно квалифицированными, 2. дизайн взаимодействия потоков, основанный на сигналах, дубово-качественным.

ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D

А без придалбывания к словам? Ну замени sed'ом «IPC» на «взаимодействие потоков», если ты это по контексту не допёр.

Они на то и потоки, что им IPC нафиг не нужен. Ты википедию так и не открыл поди?

Давай, съезжай на личности дальше.

Сказал персонаж, и начавший сей процесс :D Есть что сказать, говори по делу.

Я достаточно натрахался с быдлокодом любителей сигналов в другие потоки, чтобы не считать 1. мир идеальным, а разработчиков поголовно квалифицированными, 2. дизайн взаимодействия потоков, основанный на сигналах, дубово-качественным.

Я достаточно натрахался с быдлокодом как таковым и поработал с кодом на целой прорве разных языков (от ковыряния в чужом и хорошем коде, и в говнокоде, до проектирования и реализации проектов своими руками), чтобы 1 не считать что выбор инструмента (ЯП, тулкида, парадигмы, патернов и т.д.) может как-то повлиять на качество работы быдлокодера 2 не считать вообще хоть что-то дубовым и не ломаемым кривыми ручками 3 не считать проектирование менее или более важным чем качество реализации. ЗЫ И достаточно опытный специалист чтобы понимать, что создать качественный код можно только руками хороших спецов и что его создать таки можно. Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).

А без придалбывания к словам?

А без влажных фантазий о собеседнике в неизвестном конце глобальной сети?

Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).

Таких проектов куча. В моем случае это легаси + пачка быдлокодеров со стороны заказчика, которых по этой причине не уволить. Вопросы задавать круто, но на код это не повлияет и с ним надо работать. Взять и переписать нереально, можно только материться и дебажить бесконечные рейсы и дедлоки.

не считать что выбор инструмента (ЯП, тулкида, парадигмы, патернов и т.д.) может как-то повлиять на качество работы быдлокодера

не считать проектирование менее или более важным чем качество реализации.

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

Таких проектов куча. В моем случае это легаси + пачка быдлокодеров со стороны заказчика, которых по этой причине не уволить. Вопросы задавать круто, но на код это не повлияет и с ним надо работать. Взять и переписать нереально, можно только материться и дебажить бесконечные рейсы и дедлоки.

Такова наша жизнь. Мне тоже приходиться в куче какашек барахтаться. Но первопричина как была так и есть быдлокодеры.

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

Усложнит, но не избавит - раз. Нагромождение защиты от самострелов даёт накладники - два.

Будь то GC, хитрый тулкит или ещё что, один хрен слишком много накладников и всё равно говнокод (и как правило качество кода только падает тем сильнее чем больше защиты от дурака и не важно на каком уровне защита, если это не отдел кадров). Хороший дизайн и правильный инструментарий помогут всё сделать хорошо, но только помогут, а не обеспечат. К сожалению, приходится сталкиваться с говнокодом из разных источников. И повлиять нету возможности ни на качество реализации, ни на качество проектирования, ни на правильный выбор инструментария. Ковырял я говнокод написанный и на C/C++, и на Qt, и STL, и на дикой каше из разношёрстных либ, и на С#, и жабе, и на CMD и shell script. И были там вещи загнанные в состояние УГ ещё на этапе проектирования и с хорошим изначально дизайном. И писал я и на STL, и на Qt, и на жабе, шарпе, шелле и прочем, прочем, прочем. Могу сказать, что правильные спецы могут делать как минимум сносно с любым инструментарием, но лучше если полагаться не на защиты от дураков, а мозг, как на этапе проектирования так и реализации. Эффективен лишь отсев дебилов, остальное не спасает. А ссылки на сторонний код лишь пустозвонство, наворотят говно из чего угодно и чем угодно и тут ты не повлияешь никак всё равно.

Усложнит, но не избавит - раз.

Конечно.

Нагромождение защиты от самострелов даёт накладники - два.

Самое оно для дебаг-билдов. И проверять на правильный поток в методах, и добавлять другие проверки...

Раньше была tbb, сейчас не знаю.