.NET 中哪些阻塞线程操作会在阻塞时处理 COM 消息？
当创建新的 STA 线程来托管 STA COM 组件时，该线程负责泵送与 COM 相关的 Windows 消息。据我所知，某些内置的 .NET 线程原语（例如锁（Monitor.Enter））将在等待另一个线程释放对象时为您执行此操作。我见过的另一种为您制作 .NET 泵 COM 消息的方法是使用 .Join()。
在哪里可以找到具有此行为的内置线程原语的完整列表？等待 WaitHandle 会支持这一点吗？ WaitAny() 或 .NET 4 中新的并发集合怎么样？我无法在任何特定方法的文档中找到这一点。
When creating a new STA thread to host an STA COM component, it is the responsibility of that thread to pump Windows messages related to COM. From what I've been able to gather, certain built in .NET threading primitives such as lock (Monitor.Enter) will do this for you while waiting for the object to be released by another thread. Another way of making .NET pump COM messages for you that I've seen is to use .Join().
Where can I find a complete list of built in threading primitives with this behaviour? Would waiting on a WaitHandle support this? What about WaitAny(), or the new concurrent collections in .NET 4? I'm unable to find this in the documentation for any of the specific methods.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这可以从 SSCLI20 源进行某种程度的逆向工程，尽管它已经过时了。实现MsgWaitForMultipleHandles 的核心CLR 函数是DoAppropriateWait。据我所知，它被 AutoResetEvent、ManualResetEvent 和 Semaphore 使用，但 Mutex 不使用它。一个怪癖是，STA 线程中的 WaitHandle.WaitAny 没问题，但 WaitAll() 会生成异常。是的，除了 Chris Brumme 博客中的一些提示之外，其他任何地方都没有记录这一点。你不能从我的发现中假设太多，请测试一下以确定。
This can be reverse-engineered somewhat from the SSCLI20 source, albeit that it is dated. The core CLR function that implements MsgWaitForMultipleHandles is DoAppropriateWait. From what I see, it is used by AutoResetEvent, ManualResetEvent and Semaphore but not by Mutex. One quirk is that WaitHandle.WaitAny is okay from an STA thread but WaitAll() generates an exception. Yeah, this isn't documented anywhere other then a few hints in Chris Brumme's blog. You can't assume too much from what I found, test this to be sure.