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

[Old]

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

В любую нормальную очередь мы передаем работу в виде функтора/лямбды. Никто не мешает передавать в ней callback-функцию, которая будет вызываться в конце работы. Так мы можем контролировать завершение каждой конкретной работы, а не всех вместе.
 

[Igors]

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

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

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

Я надыбал пример для 1.66, а у меня стоит 1.59. Переставлять "чревато" т.к. 1.59 используется в рабочих проектах. Ладно, погнал по хедерам. Хирак - не линкует. Пытался подлить еще хедеров - ни фига. Потом дошло - для pthread нужны либы. Правда их компиляция и добавление прошло с пол-пинка, но пока сообразишь...

Ладно, разбираюсь. Метод join всего лишь завершение ниток, если его просто так позвать - то висит и все. Оказывается сперва надо сделать closе (закрыть очередь). Но это всего лишь "закрыть пул", а удобного метода waitFotDone просто НЕТУ, пришлось сделать самому, псевдокод

Код

C++ (Qt)
// worker
void MyTask::operator()( void )
{
  ....
  if (--MyTask::taskCount <= 0) {
    std::unique_lock..
    MyTask::cond.notify_one();
  }
}
 
// main thread
MyTask::taskCount = tasks.size();
for (int i = 0; i < tasks.size(); ++i
 pool.submit(tasks[i]);
 
while (MyTask::taskCount) {
 std::unique_lock..
 MyTask::cond.wait(lock);
}

На мелких задачах производительность также садится, но "запас прочности" побольше чем у QThreadPool. В принципе тул неплохой, но ни доки ни примеров - ни хрена нету   Тратить время на разборки (да еще и с каждой версией) - непозволительная роскошь для профессионала.

[m_ax]

В любую нормальную очередь мы передаем работу в виде функтора/лямбды. Никто не мешает передавать в ней callback-функцию, которая будет вызываться в конце работы. Так мы можем контролировать завершение каждой конкретной работы, а не всех вместе.

Вот.. Я вначале тоже думал, что можно завести список флажков и передавать его в лямбду. Но.. Но это означает, что потребитель должен в "холостую" крутится в цикле, опрашивая каждый раз, не завершились ли все задачи.. Это немного напрягает.. Футура, на мой взгляд, здесь более логичное решение..

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

Это почему же?

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

Здесь особого секрета нет. Время t2 - это время когда нам нужно заблочить мьютекс, взять задачу, сделать pop у очереди и освободить мьютекс. Если Вы в очередь кидаете мульён мелких задач (у которых время выполнения сопостоаимо с описанной выше ситуацией) в один присяд, то Вы неменуемо свалитесь в пробку.

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

Что значит откуда?
Мы же это уже обсуждали..  Там не нужно каких то фундаментальных теорий.. Я сейчас говорю, опираясь на обозначенную мной проблему.. В этой ситуации ответ очевиден:  нужно сделать очередь как можно меньше, а задачи, как можно более жирными.

а удобного метода waitFotDone просто НЕТУ

Вот, я как раз и хотел заиметь этод метод, и, как следствие, мой велик..

[m_ax]

Так что там с реализацией на атомиках онли?

[m_ax]

Оказывается сперва надо сделать closе (закрыть очередь).

На сколько я понимаю, это костыль в контекте моей проблемы..((

[Old]

Оказывается сперва надо сделать closе (закрыть очередь).

На сколько я понимаю, это костыль в контекте моей проблемы..((

Что за пул из буста вы обсуждаете, у которого есть метод close?

[m_ax]

Что за пул из буста вы обсуждаете, у которого есть метод close?

Не знаю Я имею в виду пул из asio)

[m_ax]

Я уже плохо соображаю сейчас  

Я хотел там найти, но не нашёл метода типа waitFotDone

[m_ax]

Оказывается сперва надо сделать closе (закрыть очередь).

На сколько я понимаю, это костыль в контекте моей проблемы..((

Что за пул из буста вы обсуждаете, у которого есть метод close?

А там и нет такого метода.. Поддался на мнения igors'а))

[Old]

Вот.. Я вначале тоже думал, что можно завести список флажков и передавать его в лямбду. Но.. Но это означает, что потребитель должен в "холостую" крутится в цикле, опрашивая каждый раз, не завершились ли все задачи.. Это немного напрягает.. Футура, на мой взгляд, здесь более логичное решение..

Вместо флажков можно было передавать std::promise, а полученные из него std::future использовать для ожидания.
Те же яйца только в профили.

[m_ax]

Вместо флажков можно было передавать std::promise, а полученные из него std::future использовать для ожидания.
Те же яйца только в профили.  

Согласен) Но тем не менее это лишние Телодвижения) Которых хотелось бы избежать)

[Old]

Согласен) Но тем не менее это лишние целодвижения) Которых хотелось бы избежать)

Этот прием можно использовать, если пул сам не умеет в футуры.
 

[m_ax]

Этот прием можно использовать, если пул сам не умеет в футуры.  

Согласен)) Но это всё же лишние телодвижения.. Я так делать не хочу( 

[Igors]

А там и нет такого метода..

Метод close есть

Код

C++ (Qt)
    /**
     * \b Effects: close the \c basic_thread_pool for submissions.
     * The worker threads will work until there is no more closures to run.
     */
    void close()
    {
      work_queue.close();
    }
 

Хедер в аттаче. А метода waitForDone (по аналогии с QThreadPool) нету о чем я Вам сообщил большими буквами.

Поддался на мнения igors'а))

А разве я Вас чем-то обманул?

Футура, на мой взгляд, здесь более логичное решение..

А у Вас здесь есть какой-то интерес к "именно этой/конкретной задаче" чтобы ее мониторить? Нет. Так зачем бездумно добавлять еще какие-то обертки/обвязки? Только потому что это "std" и, значит, "уже хорошо"?

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

[Old]

А разве я Вас чем-то обманул?

Вы писали что попробовали бустовский пул. В бусте пул поток есть только в asio и это не то, что пробовали вы. У вас какая то библиотека не буста.

Если атомарный счетчик вызывает у Вас затруднения (не знаю почему)

Вам уже много раз говорили, что для организации эффективного ожидания атомарных счетчиков не достаточно.