原副标题：在界面缓存上等候的危害性
他们做这么两个假定哈。
假如有两个缓存，它拥有两个询问处，则在这个缓存的整个运转操作过程中，他们都不应该调用 Sleep 函数。为什么？
因为 Sleep 调用会引致缓存在睡眠等候期暂停处置询问处最新消息。即使对日照时间较长的午睡也是如此，比如午睡几秒和醒过来以HTTP控制系统中这类内容的状况。
如我之前在另一则该文中所提及的，HTTP会降低控制系统操控性，还会侵害控制系统在高效能情况下省水的能力，并受到终端服务器的弱化负面效应的影响。
假如当前处置器处于空余状况，那就竭尽全力保持很忙。假如处置器想来，那就急忙让它完成计算任务，然后重新回到空余状况。
但有时我还是会看到如下表所示的标识符：
请注意，此最新消息循环式长达四分钟而不处置最新消息。人们通常不能将四分钟的午睡填入负责与终端使用者可视化的缓存中，但他们时常为前台工作缓存竭尽全力执行此操作，这些缓存为跨缓存通讯目的建立了暗藏询问处。虽然缓存没有由此可见的 UI，因而将终端使用者一次挂起几秒是不能有明显的交互的。
但是，存在这类特殊情况。
假如控制系统须要该台最新消息，则要等候此休眠状态缓存最终唤起并处置该台最新消息。同时，收到该台的模块竭尽全力等候。比如，使用者可能将holds了须要 DDE 才能关上的文件格式。DDE 操作过程从该台 WM_DDE_INITIATE 最新消息开始，该最新消息停滞不前在询问处前面。你的无积极响应暗藏询问处刚刚建立了两个 “Windows 似乎以乱数间距挂起几秒” 严重错误。
请注意，许多人忽视了调用 CoInitialize（可能将间接地）来调用 STA 的缓存会建立两个暗藏询问处以竭尽全力执行列集。因而，在单缓存模块中运转的缓存要时不时地处置最新消息。假如不这样做，虽然询问处无积极响应，将引致谜样的控制系统级雅雷。
归纳
对在界面缓存中竭尽全力执行的标识符，我的看法是：不是非常必要性，都不要使用 Sleep。
人的生命是有限的，软件运转的快，是两个终极需求。
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对广大Windows平台开发者来说，确实十分有帮助。
本文来自：《The dangers of sleeping on a UI thread》
