何时使用TaskCreationOptions.LongRunning? [英] When to use TaskCreationOptions.LongRunning?

问题描述

我已经想了很久了，但从未真正找到答案.

I've wondered this for quite a while, but never really found the answer.

我了解这是任务计划程序将在其上运行的提示，并且任务计划程序可以(或者现在是?)决定为该任务实例化非线程池线程.

I understand that it's a hint for the task scheduler where the task will run on, and that the task scheduler can (or nowadays will?) decide to instantiate a non-thread-pool thread for that task.

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

What I don't know (and surprisingly can't find nowhere on the internet) is some "rule of thumb" when to specify a task as long-running. Is one second long? 30 seconds? A minute? 5 minutes? Does it have a relation with the amount of tasks the application uses? Should I as programmer do some calculation with the #threads in the thread pool, how many Tasks I create, how many will be long-running at the same time, and based on that make a decision whether to use a long running task?

希望在这里学点东西.

推荐答案

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

It can be quantified, the threadpool manager adds an extra thread beyond the optimum when the existing tp threads don't complete soon enough. It does this twice a second, up to the maximum set by SetMaxThreads(). Which has a very high default value. The optimum is the number of processor cores the machine has available, 4 is typical. Running more threads than available cores can be detrimental due to the context switching overhead.

它基于假设来执行此操作，因为这些现有线程没有执行足够的代码，因为它们未执行足够的代码.换句话说，它们过多地阻塞了I/O或锁定.因此，此类线程无法充分有效地利用内核，而允许执行额外的线程完全适合提高处理器使用率并完成更多工作.

It does this based on the assumption that these existing threads don't make progress because they are not executing enough code. In other words, they block on I/O or a lock too much. Such threads therefore don't use the cores efficiently enough and allowing an extra thread to execute is entirely appropriate to drive up processor usage and get more work done.

因此，当线程花费半秒以上的时间时，它是长期运行的".请记住，这是一个很长的时间，大约相当于现代台式机上40亿个处理器指令.除非您运行计算量大的代码(例如将pi的值计算为万亿位，从而实际执行这40亿条指令)，否则实际线程只有在经常阻塞时才会花费这么长时间.这是很常见的，诸如dbase查询之类的查询通常很慢，并且在工作线程上执行，并且消耗的CPU很少.

So it is "long running" when the thread takes more than half a second. Keep in mind that this is a very long time, it equals roughly 4 billion processor instructions on a modern desktop class machine. Unless you are running computationally heavy code like calculating the value of pi to a gazillion digits, thus actually executing those 4 billion instructions, a practical thread can only take this long when it does block too often. Which is very common, something like a dbase query is often slow and executed on a worker thread and consumes little cpu.

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

It is otherwise up to you to verify that the assumption that the threadpool manager will make is accurate. The task should take a long time because it isn't using the processor efficiently. Task Manager is a simple way to see what the processor cores are doing in your program, albeit that it won't tell you exactly what code they are executing. You'll need a unit test to see the thread executing in isolation. The ultimate and only completely accurate way to tell you that using LongRunning was an appropriate choice is to verify that your app indeed gets more work done.

这篇关于何时使用TaskCreationOptions.LongRunning?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！