多线程作业队列管理器

我需要在交互式应用程序中管理CPU繁重的多任务作业.同样背景,我的具体应用是工程设计界面.当用户调整模型的不同参数和选项时,会在后台运行多个模拟,并在完成时显示结果,即使用户仍在编辑值时也是如此.由于多次模拟需要可变时间(有些是几毫秒,有些需要5秒,有些需要10分钟),所以基本上是尽可能快地显示反馈,但通常会中止以前开始但现在不再需要的作业,因为用户的更改已经使它们无效.不同的用户更改可能使不同的计算无效,因此在任何时候我可能有10个不同的模拟运行.

我非常有信心处理这种应用程序的代码级方法是某种多线程作业队列.这将包括提交作业以执行,设置任务优先级,等待作业完成,指定依赖项(执行此作业,但仅在作业X和作业Y完成后),取消符合某些条件的作业子集,查询内容的功能工作仍然存在,设置工作线程计数和优先级等等.多平台支持也非常有用.

这些不是软件中的新想法或愿望,但我处于应用程序的早期设计阶段,我需要选择用于管理此类任务的库.我过去在C中编写了我自己的粗线程管理器(我认为这是一个通过的仪式)但我想使用现代工具来开展我的工作,而不是我以前的hacks.

首先想到的是运行OpenMP,但我不确定这是我想要的.OpenMP非常适合在精细级别进行并行化,自动展开循环等.虽然是多平台,但它也会用#pragmas侵入您的代码.但主要是它不是为管理大型任务而设计的.尤其是取消挂起的作业或指定依赖项.可能,是的,但它并不优雅.

我注意到Google Chrome使用这样的作业管理器来完成最琐碎的任务.设计目标似乎是保持用户交互线程尽可能轻巧灵活,因此任何可以异步生成的东西都应该是.从查看Chrome源代码来看,这似乎不是一个通用库,但看看设计如何使用异步启动来保持交互速度仍然很有趣.这与我正在做的类似.

还有其他选择:

Surge.Act:用于定义作业的类似Boost的库.它建立在OpenMP之上,但允许链接依赖项,这很好.它似乎并不觉得它有一个可以查询的经理,取消工作等等.这是一个陈旧的项目所以依赖它是可怕的.

Job Queue非常接近我的想法,但它是一篇5年前的文章,而不是受支持的库.

Boost.threads确实有很好的平台独立同步,但那不是一个职业经理.POCO具有非常干净的任务启动设计,但同样不是链接任务的完整经理.(也许我低估了POCO).

因此,虽然有可用的选项,但我不满意,我觉得再次推出自己的库的冲动.但我宁愿使用已经存在的东西.即使在搜索之后(这里在SO和网上)我也没有发现任何感觉正确的东西,尽管我认为这必须是一种经常需要的工具,所以肯定有一些社区库或至少是常见的设计.在SO上有关于工作队列的一些帖子,但似乎没有任何东西适合.

我在这里的帖子是问你所有我错过的现有工具,和/或你如何推出自己的多线程作业队列.

我们必须构建我们自己的作业队列系统以满足与您类似的要求(UI线程必须始终在33ms内响应,作业可以在15-15000ms之间运行),因为那里确实没有任何东西可以满足我们的需求,更不用说是高性能了.

不幸的是,我们的代码与专有内容一样专有,但我可以为您提供一些最显着的功能:

我们在程序开始时为每个核心启动一个线程.每个从全局作业队列中提取工作.作业由一个函数对象和一组关联数据组成(实际上是对func_ptr和void*的详细说明).线程0(快速客户端循环)不允许在作业上工作,但其余部分尽可能地抓取.

作业队列本身应该是一个无锁数据结构,例如无锁单链表(Visual Studio 附带一个).避免使用互斥锁; 对队列的争用非常高,抓住互斥体的成本很高.

将作业的所有必要数据打包到作业对象本身 - 避免将指针从作业返回到主堆中,在那里您将不得不处理作业和锁之间的争用以及所有其他缓慢,恼人的事情.例如,所有模拟参数都应该进入作业的本地数据blob.结果结构显然需要比工作更长的事情:你可以通过以下方式处理:a)即使在完成运行后挂在工作对象上(这样你就可以使用主线程中的内容),或者b)为每个作业专门分配结果结构,并将指针填充到作业的数据对象中.尽管结果本身不会存在于作业中,但这有效地使作业可以独占访问其输出内存,因此您无需使用锁定.

实际上我正在简化一点,因为我们需要准确地编排哪些作业在哪个核心上运行,所以每个核心都有自己的作业队列,但这对你来说可能是不必要的.

我根据Boost.threads推出了自己的产品.我写这么少的代码后,我感到非常惊讶.如果您没有找到预先制作的东西,请不要害怕自己动手.在Boost.threads和你自己编写自己的经历之间,它可能比你记忆容易.

对于预制选项,不要忘记Chromium的许可非常友好,因此您可以围绕其代码滚动自己的通用库.