【发布时间】:2015-03-27 08:20:18
【问题描述】:
我们有一个应用程序有一些时间限制,假设我们需要每 500 毫秒执行一次操作,它是一种看门狗,所以如果我们在 500 毫秒之前不发送消息,就会发生坏事。
应用程序大量使用 ThreadPool,而这个看门狗事物与 ThreadPool 交互。
我们发现在一些低端机器上,有时当我们排队一个新的工作项时,执行它需要大约 800 毫秒,因此看门狗会触发。我们猜测这与 ThreadPool 线程耗尽/创建新线程有关。
有没有办法避免这种情况,例如强制 ThreadPool 提前或在不同的线程中创建线程,这样看门狗就不必等到 ThreadPool 可以执行请求?
【问题讨论】:
-
是的,有办法。但是,为什么您发现自己首先用完了 ThreadPool 线程?也许值得看看在哪里可以使用异步 I/O 而不是阻塞 I/O?
-
这个“看门狗”是否在其专用线程上运行?
-
@Magnus:它在专用线程上运行,而不是来自线程池,但它一直等到收到来自线程池线程的消息。
-
线程池只用于这个任务吗?这是一些计划任务,应该每 500 毫秒触发一次,并且可能有更多并发的任务实例?
-
@user3360241:不,theadpool 用在好几个地方。
标签: c# .net multithreading threadpool timing