阻塞线程占用了哪些资源

Question

在异步编程模型中编写代码的主要目的之一(更具体地说 - 使用回调而不是阻塞线程)是为了最小化系统中阻塞线程的数量.

对于运行线程,由于上下文切换和同步成本,这个目标是显而易见的.

但是被阻止的线程呢？为什么减少它们的数量如此重要？

例如,在等待来自Web服务器的响应时,线程被阻塞,并且不占用任何CPU时间,并且不参与任何上下文切换.

所以我的问题是:除了RAM(每个线程大约1MB？)阻塞线程占用了哪些其他资源？

另一个更主观的问题是:在什么情况下,这个成本真的证明了编写异步代码的麻烦(例如,价格可能是将你的好的连贯方法拆分为大量的beginXXX和EndXXX方法,并将参数和局部变量移动到类字段).

更新 - 我没有提及或没有给予足够重视的其他原因:

1. 更多线程意味着更多地锁定公共资源

2. 更多线程意味着更多创建和处理线程,这是昂贵的

3. 系统肯定会耗尽线程/ RAM然后停止服务客户端(在Web服务器方案中,这实际上可以降低服务)

Answer 1

所以我的问题是:除了RAM(每个线程大约1MB？)阻塞线程占用了哪些其他资源？

这是最大的一个.话虽这么说,有一个原因是.NET中的ThreadPool允许每个核心有这么多线程 - 在3.5中,默认情况下系统中每个核心有250个工作线程.(在.NET 4中,它依赖于系统信息,如虚拟地址大小,平台等 - 现在没有固定的默认值.)线程,特别是被阻塞的线程,真的不是那么昂贵......

但是,我会说,从代码管理的角度来看,值得减少阻塞线程的数量.每个被阻塞的线程都是一个应该在某个时刻返回并被解除阻塞的操作.拥有许多这些意味着您需要管理相当复杂的代码集.保持这个数字减少将有助于保持代码库更简单 - 更易于维护.

另一个更主观的问题是:在什么情况下,这个成本真的证明了编写异步代码的麻烦(例如,价格可能是将你的好的连贯方法拆分为大量的beginXXX和EndXXX方法,并将参数和局部变量移动到类字段).

现在,这通常很痛苦.这很大程度上取决于场景.但是Task<T>,.NET 4中的类在很多情况下都会对此进行改进.使用TPL,它比以前使用APM(BeginXXX/EndXXX)甚至EAP要痛苦得多.

这就是为什么语言设计师在未来努力改善这种情况的原因.他们的目标是使异步代码更容易编写,以便更频繁地使用它.