我有一个这样的脚本：

#!/bin/bash
for i=1 to 200000
do
create input file
run ./java
done

我需要同时运行一个(8或16)个进程(java),我不知道如何.我知道等待可能会有所帮助,但它应该始终运行8个进程,而不是等待前8个进程完成其他8个进程.

bash 4.3为wait命令添加了一个有用的新标志,-n,这会导致等待阻塞,直到完成任何单个后台作业,而不仅仅是给定子集(或所有)的成员.

#!/bin/bash
cores=8  # or 16,or whatever
for ((i=1; i <= 200000; i++))
do
    # create input file and run java in the background.
    ./java &

    # Check how many background jobs there are,and if it
    # is equal to the number of cores,wait for anyone to
    # finish before continuing.
    background=( $(jobs -p) )
    if (( ${#background[@]} == cores )); then
        wait -n
    fi
done

存在一个小的竞争条件：如果您处于最大负载但是在运行作业后作业完成-p,您仍将阻止直到另一个作业
完成.你无能为力,但在实践中不应该有太多麻烦.

在bash 4.3之前,您需要定期轮询后台作业集,以查看池何时降至阈值以下.

while :; do
    background=( $(jobs -p))
    if (( ${#background[@]} < cores )); then
        break
    fi
    sleep 1
done

假设我有许多使用boost :: statechart定义的异步状态机.用于运行多个异步状态机的明确记录的机制是将一个或多个异步状态机固定到线程.但是,出于我的目的,我需要运行许多很多异步状态机,每个线程一个不会.此外,任何给定状态机完成的工作量是不可预测的,因此将状态机分配给固定线程将导致不平衡.

相反,我想要一个线程池,其中空闲线程可以从队列中获取一些工作量.需要注意这一点,以便按顺序传递给定状态机的事件.据推测,开始的地方将涉及实现调度程序和可能的FifoWorker概念,以分别执行我想要的替代fifo_scheduler和fifo_worker类的操作.但是,我想知道这个问题是否已经被其他人解决了,或者我是否只是提出了错误的问题.

回答我自己的问题,现在我有时间考虑一下.这很简单：

>每个状态机都有自己的fifo_scheduler
>当我们希望状态机开始运行时,会向线程池发布一个函数：

>检查scheduler.terminated()并停止,如果是这样.
>运行调度程序(n),其中n是某些与实现相关的值.我们需要这样做以防止饥饿.
>将自己发布回线程池.

这也确保了事件按顺序传递而无需借助其他方法.

这不是最好的答案,因为服务功能将占用队列中的空间,即使没有工作要做也可以调用.

我正在编写一个光线投射游戏引擎.
可以在不知道任何其他光线的情况下计算每条光线(我只计算距离).
由于计算之间没有等待时间,我想知道是否值得努力使光线计算成为多线程.
是否可能会提升性能？

如果正确完成,多线程很可能会提高性能.您已经说明了问题的方式,它是多线程的理想选择,因为计算是独立的,可以将线程之间的协调需求降至最低.

有些原因你仍然可能无法加速,或者可能无法达到预期的全速,可能包括：

1)瓶颈可能不是片上cpu执行资源(例如,ALU绑定操作),而是像存储器或共享LLC带宽那样共享的东西.

例如,在某些体系结构上,单个线程可能能够使内存带宽饱和,因此添加更多内核可能无济于事.更常见的情况是单个核心可以使一些分数饱和,1 / N <1.主存储器带宽为1,该值大于1 / C,其中C为核心计数.例如,在4核盒上,一个核心可能能够消耗50％的带宽.然后,对于内存限制计算,您将获得良好的扩展到2个内核(使用100％的带宽),但几乎没有. 核心之间共享的其他资源包括磁盘和网络IO,GPU,窥探带宽等.如果您有超线程平台,则此列表会增加,以包括共享相同物理核心的逻辑核心的所有级别的缓存和ALU资源. 2)在“理论上”独立的操作之间“在实践中”的争用. 你提到你的操作是独立的.通常这意味着它们在逻辑上是独立的 – 它们不共享任何数据(除了可能不可变的输入之外)并且它们可以写入单独的输出区域.然而,这并不排除这种可能性,因为任何给定的实现实际上都有一些隐藏的共享. 一个典型的例子是错误共享 – 其中独立变量属于同一缓存行,因此从不同线程对不同变量的逻辑独立写入最终会破坏核心之间的缓存线. 在实践中经常遇到的另一个例子是通过库进行争用 – 如果你的例程大量使用malloc,你可能会发现所有线程都花费大部分时间等待分配器内的锁定,因为malloc是共享资源.这可以通过减少对malloc的依赖(可能通过更少,更大的malloc)或使用良好的并发malloc(如hoard或tcmalloc)来解决. 3)跨线程分配和收集计算的实现可能会压倒你从多个线程获得的优势.例如,如果为每个单独的光线启动一个新线程,则线程创建开销将主导您的运行时,您可能会看到负面的好处.即使您使用持久线程的线程池,选择太细粒度的“工作单元”也会产生大量协调开销,这可能会消除您的好处. 同样,如果必须将输入数据复制到工作线程和从工作线程复制,您可能看不到预期的缩放.在可能的情况下,对只读数据使用pass-by-reference. 4)你没有超过1个核心,或者你有超过1个核心,但它们已经被占用运行其他线程或进程.在这些情况下,协调多个线程的工作是纯粹的开销.