【发布时间】：2010-10-07 02:06:29
【问题描述】：
我有一个关于解决异步应用程序故障的理论（我正在使用 CCR），我想知道是否有人可以证实我的逻辑。
如果使用默认线程数（即每个内核一个）的基于 CCR 的多线程应用程序比指定双倍线程的同一应用程序慢 - 这是否意味着线程在代码中的某处被阻塞
你怎么看？这是检测线程是否被无意阻塞的快速有效的方法吗？
【问题讨论】：
标签： asynchronous ccr blocked-threads
【发布时间】：2010-10-07 02:06:29
【问题描述】：
“慢”是什么意思？
如果您想自动检测被阻塞的线程，也许这些线程应该发送一个心跳，然后由某种监视器观察，但您的选择是有限的。
【讨论】：
判断线程是否被阻塞的一种廉价方法是在执行任何可能的阻塞操作之前获取当前系统时间，然后在操作之后查看已经过去了多少时间。例如，在等待消息到达时，测量线程在等待消息到达时阻塞了多长时间。
除非总是有足够多的消息要处理，否则线程将阻塞等待消息。如果您有更多线程，那么您就有更多潜在的消息生成器（取决于您的设计），因此等待接收消息的线程更有可能准备好一个。
只有一个 CPU 线程太少，除非你能保证总是有足够的消息，所以没有线程需要等待。
【讨论】：
如果是这种情况，则意味着您的线程池已用尽（即您有 2 个线程，但您已异步挂起 4 个 IO 或其他东西） - 如果您的工作受大量 IO 限制，则“每个线程一个线程”的规则核心”并不真正适用。
【讨论】：
-
是的，我正在执行 IO 操作（Web 服务和 SQL DB 调用）
我发现为了使用最少的线程来保持系统流畅，我使处理 I/O 的任务尽可能简洁。他们只是将来自 I/O 的数据发布到另一个端口而不做进一步的处理。因此，数据在其他地方排队等待以受控方式进行处理，而不会干扰尽可能快地获取数据的任务。如果要考虑共享状态，则此处理可能发生在 Interleave 的 ExclusiveGroup 中......并且一个方便的副作用是独占任务永远不会占用 Dispatcher 中的所有线程（但是，我怀疑可能有更简洁的方法在 CCR API 中管理它）
【讨论】：