在阅读本文中的线程池和任务如何工作后,我提出了这个问题 -
如果我有一个复杂的程序,其中一些模块使用tasks
和一些使用thread pool
,是否会由于用途不同而出现一些调度问题?
在阅读本文中的线程池和任务如何工作后,我提出了这个问题 -
如果我有一个复杂的程序,其中一些模块使用tasks
和一些使用thread pool
,是否会由于用途不同而出现一些调度问题?
任务通常使用线程池来实现(当然也可以使用其他类型的调度程序来执行任务,这些调度程序会提供不同的行为,但这是默认设置)。就正在执行的实际代码而言(假设您的任务代表正在运行的委托),实际上并没有太大区别。
任务只是围绕该线程池调用创建一个包装器,以在收集有关该异步操作的信息和处理该异步操作的结果时提供附加功能。如果您想利用该附加功能,请使用任务。如果您不需要在某些特定上下文中使用它,那么直接使用线程池并没有错。
将两者混合使用,只要您从这些操作的结果中得到您想要的结果没有问题,就根本不是问题。
不,不会有问题——你只是在这两个方面都效率低下。使用真正需要的东西并坚持这种模式。请记住确保您的应用程序 MT 安全,尤其是当您从不同的线程访问相同的资源/变量等时,无论您使用哪种线程算法。
不。实际上,在混合方法时,内存或性能效率低下的方式并不多;默认情况下,任务使用与线程池线程相同的线程池。
混合两者的唯一显着缺点是代码库缺乏一致性。如果你要选择一个,我会使用 TPL,因为它有丰富的 API 用于处理多线程的许多方面,并利用 async/await 语言特性。
由于您的使用被划分为模块行,因此您不必担心太多。
不应该有任何调度问题,但当然最好使用任务并让框架决定如何处理调度的工作。在当前版本的框架(4.5)中,除非使用 LongRunning 选项,否则工作将通过 ThreadPool 排队,但这种行为当然可能会在未来发生变化。
结论:混合任务和线程池不是问题,但对于新应用程序,建议使用任务而不是直接在线程池上排队工作项(原因之一是线程池在 Windows 8 运行时不可用(现代 UI 应用程序) .