线程池 - 老板/工人与同行（工作人员）模型

Question

我的目标是使用带有 pthreads 的线程池，并试图在这两种线程模型之间进行选择，在我看来，对等模型在使用固定输入时更合适，而老板/工人模型更好用于动态变化的工作项。但是，我有点不确定如何让对等模型与线程池一起工作。

我有许多任务都需要在同一个数据集上执行。下面是一些简单的伪代码，我将如何看待这个问题：

data = [0 ... 999]
data_index = 0
data_size = 1000

tasks = [0 ... 99]
task_index = 0    

threads = [0 ... 31]

thread_function()
{
    while (true)
    {
        index = data_index++ (using atomics)
        if index > data_size
        {
            sync

            if thread_index == 0
            {
                data_index = 0
                task_index++
                sync
            }
            else
            {
                sync
            }
            continue
        }

        tasks[task_index](data[index])
    }
}

（首先，似乎应该有一种方法可以只使用一个同步点，但我不确定这是否可能？）

上面的代码似乎适用于预先知道任务的情况，尽管我猜线程池对于这个特定问题是不必要的。然而，即使数据项仍然是在所有任务中预定义的，如果事先不知道任务，似乎老板/工人模型更适合？是否可以使用老板/工人模型，但仍然允许线程自己拾取任务（如上所述），老板基本上暂停自己，直到所有任务完成？ （也许这仍然被称为对等模型？）

最后一个问题是关于同步、障碍或条件变量，为什么？

如果有人可以就如何更好地解决这个问题提出任何建议，甚至可以戳穿我的任何假设，那会很棒吗？不幸的是，我被限制使用更高级别的库，例如 tbb 来解决这个问题。

编辑：如果不清楚，我应该指出，每个任务都需要完整地完成，然后才能进入下一个。

Answer 1

我对您在这里的描述有点困惑，希望以下内容是相关的。

我一直在看这个模式，发现它非常有用：“老板”负责检测工作并根据某种算法将其分派到工作池中，从那时起，工作人员是独立的。

在这种情况下，工作人员始终在等待工作，不知道任何其他实例、处理请求，并且当它完成时，可能会触发完成通知。 这样做的好处是工作本身和线程之间平衡的算法之间有很好的分离。

另一种选择是让“老板”维护一个工作项目池，而工人总是一有空就拿起它们。但我想这实现起来更复杂，需要更多的同步。我看不出第二种方法比前一种方法有什么好处。

在这两种情况下，控制逻辑和工人状态都由“老板”维护。 当并行工作在一个任务上完成时，“老板”“对象”正在处理一个任务，在一个简单的实现中，这个“老板”会阻塞直到任务完成，从而允许调用排队的下一个“老板”。

关于同步，除非我在这里遗漏了什么，否则您只需要同步一次即可让所有工作人员完成，并且此同步在工作人员发送完成通知的“老板”处完成。