asynchronous - 检测阻塞线程

Question

我有一个关于解决异步应用程序故障的理论（我正在使用 CCR），我想知道是否有人可以确认我的逻辑。

如果使用默认线程数（即每个内核一个）的基于 CCR 的多线程应用程序比指定双倍线程的同一应用程序慢 - 这是否意味着线程在代码中的某处被阻塞

怎么想？这是检测线程是否被无意阻塞的快速有效的方法吗？

Answer 1

“慢”是什么意思？

如果你想自动检测阻塞的线程，也许这些线程应该发送一个心跳，然后由某种监视器观察，但你的选择是有限的。

Answer 2

I've found that to keep the system fluid with minimal threads, I keep the tasks dealing with I/O as concise as possible. They simply post the data from the I/O into another Port and do no further processing. The data is therefore queued elsewhere for processing in a controlled manner without interfering with the task of grabbing data as fast as possible. This processing might happen in the ExclusiveGroup of an Interleave if there's shared state to think about... and a handy side-effect is that exclusive tasks will never tie up all the threads in a Dispatcher (however, I suspect that there's probably nattier ways of managing this in the CCR API)

Answer 3

判断线程是否被阻塞的一种廉价方法是在执行任何可能的阻塞操作之前获取当前系统时间，然后在操作之后获取当前系统时间，然后查看已经过去了多少时间。例如，在等待消息到达时，测量线程被阻塞等待消息到达的时间。

除非总是有足够多的消息要处理，否则线程将阻塞等待消息。如果您有更多线程，那么您就有更多潜在的消息生成器（取决于您的设计），因此等待接收消息的线程将更有可能准备好一个。

除非您可以保证始终有足够的消息，因此没有线程必须等待，否则只有一个 CPU 线程太少了。

Answer 4

如果是这种情况，则意味着您的线程池已用尽（即您有 2 个线程，但您已经异步挂起 4 个 IO 或其他东西） - 如果您的工作受大量 IO 限制，则“每个核心一个线程”的规则不会不是真的适用。