相关疑难解决方法(0)

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

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

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

希望在这里学点东西.

TPL使用任务计划程序来协调任务.根据官方文档,默认任务调度程序使用线程池,但如果显示TaskCreationOptions.LongRunning选项,则它将为该任务创建专用线程(A).

问题:截至目前,Visual Studio 2010的MSDN文档尚未就绪,当前的在线MSDN尚未最终确定; 有谁知道(A)是真还是假？

我正在研究任务并行库的用法,用于我正在做的工作项目,并希望了解长时间运行任务的优点/缺点.我还没有现实生活中的例子,只想了解这背后的理论.

从MSDN页面所说的任务调度程序和这个SO问题来看,似乎最好尽可能避免长时间运行的任务,这样你就不会在ThreadPool之外创建线程.但是说你确实有一项任务需要很长时间才能完成,而不是这样:

Task.Factory.StartNew(() => DoTimeConsumingWork(), TaskCreationOptions.LongRunning)

您是否可以尝试将您的工作分成更小,更快的工作单元并使用任务延续,如下所示:

Task.Factory
    .StartNew(() => DoWorkPart1())
    .ContinueWith(t => DoWorkPart2())
    .ContinueWith(t => DoWorkPart3())
    //...etc

这种方法是否会更有益,或者它试图实现的目标是否过度？