何时使用TaskCreationOptions.LongRunning？

Question

我很想知道这一点,但从未真正找到答案.

我知道这是任务调度程序的一个提示,任务调度程序将在其中运行,并且任务调度程序可以(或现在将？)决定为该任务实例化非线程池线程.

我不知道(并且令人惊讶地在互联网上找不到)是一个"经验法则"何时指定一个长期运行的任务.是一秒多长？30秒？一分钟？5分钟？它是否与应用程序使用的任务量有关系？作为程序员,我应该使用线程池中的#threads进行一些计算,我创建了多少个任务,同时长时间运行了多少个任务,并根据这个来决定是否使用长时间运行的任务？

希望在这里学点东西.

Answer 1

它可以量化,当现有的tp线程不能很快完成时,线程池管理器会添加一个超出最佳值的额外线程.它每秒执行两次,直到SetMaxThreads()设置的最大值.其中默认值非常高.最佳的是机器可用的处理器核心数,典型值为4.由于上下文切换开销,运行比可用核心更多的线程可能是有害的.

它是基于这些现有线程没有取得进展的假设,因为它们没有执行足够的代码.换句话说,它们会阻塞I/O或锁定太多.因此,这样的线程不能有效地使用核心,并且允许额外的线程执行完全适合于提高处理器使用率并完成更多工作.

所以当线程占用超过半秒时,它就是"长时间运行".请记住,这是一个很长的时间,它相当于现代桌面类机器上大约40亿处理器指令.除非你正在运行如计算圆周率的值,以一个极大的数字,因此实际执行这4个十亿指令计算重码,实际的线程只能采取这种长时,它不会阻止过于频繁.这是非常常见的,类似于dbase查询的东西通常很慢并且在工作线程上执行并且消耗很少的cpu.

否则,您需要验证线程池管理器所做的假设是否准确.任务应该花费很长时间,因为它没有有效地使用处理器.任务管理器是一种简单的方法,可以查看处理器内核在程序中执行的操作,尽管它不会准确地告诉您它们正在执行的代码.您需要进行单元测试才能看到线程是独立执行的.最终且唯一完全准确的方式告诉您使用LongRunning是一个合适的选择是验证您的应用程序确实完成了更多的工作.

Answer 2

修改汉斯的回答,我最赞同.

指定的最重要原因LongRunning是获得实际保证且几乎立即执行.不会有任何等待线程池向您的工作项发出线程.我说的是"实际上",因为操作系统可以自由安排你的线程.但是你会得到一些CPU的份额,通常不会花很长时间才能发生这种情况.

您通过指定跳转到队列前面LongRunning.如果线程池处于负载状态,则无需等待线程池每秒发出2个线程.

因此,您将使用LongRunning必须以最有效的方式但必须以及时和稳定的方式发生的事情.例如,一些UI工作,游戏循环,进度报告,......

启动和停止线程的成本大约为1ms的CPU时间.这远远超过发布线程池工作项.我只是将此基准测试为每秒发布和完成的3M项目.基准是非常人为的,但数量级是正确的.

LongRunning记录是一个提示,但它在实践中绝对有效.没有启发式将您的提示考虑在内.它被认为是正确的.