К вопросу об организации взаимодействия пула производителей и одного потребителя

[Old]

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

А вот Igors писал, что

Вам в любом случае придётся усыплять и пробуждать тпотоки..

А можно я как-нибудь попробую без этого? 

Думаете уже не будет пробовать?
Жаль.

[m_ax]

А вот Igors писал, что

Вы что, igors'а не знаете?  
Сколько у нас тут баталий уже было  

Думаете уже не будет пробовать?  

Думаю, всё) Тема выдохлась)

Ну, во всяком случае, я ответы на свои вопросы получил, и благодарен всем, кто мотивировал меня на то, чтобы разобратся в этом вопросе  
  

[Igors]

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

Оно давно готово, там кстати несложно. Но, поскольку это никого не интересует, то чего я буду лезть типа "посмотрите как я сделал!" Это ни к чему. Кстати погонял дустовский пул.

...чтобы разобратся в этом вопросе 

Развитие происходит по спирали

[Old]

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

[m_ax]

Оно давно готово, там кстати несложно. Но, поскольку это никого не интересует, то чего я буду лезть типа "посмотрите как я сделал!"  

Ну почему же, я всегда готов (как Гагарин и Титов) к конструктивному обсуждению) Так что, всегда велком)

Кстати погонял дустовский пул.

И как впечатления?)

Развитие происходит по спирали  

Да я бы не сказал.. но это уже совсем другая история, как говорил Леонид Каневский)

[Igors]

Ну почему же, я всегда готов (как Гагарин и Титов) к конструктивному обсуждению)

Ну пока еще не очень готовы Напр

Дык, нет другого разумного решения) В контексте данной задачи, всё так или иначе сводится к пулу

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

Ну и в (в сотый раз) упомяну что все это роялит если накладные расходы велики. А если они порядка 2% - то оптимизировать это нафиг надо, можно цвести, пахнуть, и считать что уже все постиг, со всем "разобрался" 

[Old]

Ну пока еще не очень готовы Напр

Ну вы то точно готовы.

Поэтому более подходящим выглядит хотя бы QtConcurrent (хотя я сам его ни разу не использовал )

Под капотом QtConcurrent/OpenMP все тот же пул потоков.

и считать что уже все постиг, со всем "разобрался"  

Вот вот.

[m_ax]

С точностью до наоборот. Пул очень хорош когда задачи возникают "спонтанно", его сила именно в "бездумности" - закинул и все. А у Вас на каждом раунде заранее известно и число задач и исходные данные для каждой. А значит вовсе необязательно "брать по одной", всегда засисяться мутексом и.т.п.

Я уже мозг сломал, обдумывая как эту проблему (помните, описанную ситуацию с босом и подчинёнными) реализовать как то иначе..
Я буду только рад новым идеям и примерам реализации этого взаимодействия  

[Old]

Я уже мозг сломал, обдумывая как эту проблему (помните, описанную ситуацию с босом и подчинёнными) реализовать как то иначе..
Я буду только рад новым идеям и примерам реализации этого взаимодействия  

В лучшем случае мы увидим решение на спинлоке.
 

[Igors]

Я уже мозг сломал, обдумывая как эту проблему (помните, описанную ситуацию с босом и подчинёнными) реализовать как то иначе..
Я буду только рад новым идеям и примерам реализации этого взаимодействия  

Да какую "эту"? У Вас же никакой проблемы нет. С такими шикарными задачами можно брать любой тул - и все получится хорошо.

QThreadPool
QtConcurrent
boost::thread_pool
OpenMP
и.т.п.

Выбирайте ЛЮБОЙ. Хотите велик, чисто для понимания? Хорошее дело. Ну и перепишите Вы эту несчастную очередь, делов на 10 мин. Чего/зачем Вы там нагородили? Зачем связались с футурой и др std::говном? Оно там 100 лет не нужно

[m_ax]

Выбирайте ЛЮБОЙ. Хотите велик, чисто для понимания? Хорошее дело. Ну и перепишите Вы эту несчастную очередь, делов на 10 мин. Чего/зачем Вы там нагородили? Зачем связались с футурой и др std::говном? Оно там 100 лет не нужно

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

Кстатии, boost::thread_pool, я там так и не увидел (может, плохо искал), как там понять, что все задачи выполнены..   

[m_ax]

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

Подождите, мы же сейчас не о пуле говорим?) С пулом уже всё понятно, мне интересно альтернативное решение, чтоб его понять и сравнить) И задачи могут быть даже самые "мелкие"..

[Old]

Кстатии, boost::thread_pool, я там так и не увидел (может, плохо искал), как там понять, что все задачи выполнены..   

Вы про пул из asio?
Там есть join().

[Igors]

Да, и по поводу лифтов. Типичная задача оптимизации, наверняка хорошо известная. Ну ладно, допустим мы хотим это как-то приспособить к "разпоточиванию".

Начало: очевидно "число лифтов" - это у нас "число ядер". Уже тут должен сработать рефлекс типа "ой, что-то слишком гладко, не к добру"

Позиция 1: если есть какое-то "расписание лифтов", то в любой лифт студент уже не полезет. Чему это соответствует в multi-threading? Что задачи должны иметь специфику и выполняться на определенных рабочих нитках (а не на каждой). Так бывает лишь "иногда". Впрочем это еще цветочки

Позиция 2: а вот времена t1 и t2 - уже ягодки. Для задачи оптимизации они действительно необходимы, но как (или куда) воткнуть их в multi-threading?

"Контрольный выстрел": и оказывается надо еще заранее иметь готовое аналитическое решение, а откуда его брать - хз.

Вывод: да, и "разпоточивание" и задачи оптимизации часто стремятся "наилучшим образом распределить имеющиеся ресурсы", но на этом всякое сходство заканчивается. Multi-threading не имеет ничего общего с аналитической оптимизацией. С теорией игр - тем более. Вот для "моделирования" можно/удобно использовать N лифтов-ниток, но это уже "совсем другая история"

[m_ax]

Джентельмены) Должен откланиться, срочно убегаю) На последние два поста отвечу позже)