哪些阻塞操作会导致 STA 线程泵送 COM 消息？

当在 STA 线程上实例化 COM 对象时，该线程通常必须实现消息泵，以便编组与其他线程之间的调用（请参阅here).

人们可以手动发送消息，或者依赖于某些事实，但不是所有的，线程阻塞操作将在等待时自动泵送 COM 相关消息。该文档通常无助于确定哪个是哪个（请参阅这个相关问题).

如何确定线程阻塞操作是否会在 STA 上泵送 COM 消息？

到目前为止的部分列表：

阻塞操作do pump*:

• Thread.Join
• WaitHandle.WaitOne/WaitAny/WaitAll (WaitAll但不能从 STA 线程调用）
• GC.WaitForPendingFinalizers
• Monitor.Enter（因此lock) - 在某些条件下
• ReaderWriterLock
• 阻塞收集

阻塞操作do not pump:

• Thread.Sleep
• Console.ReadKey（在某处读过）

*Note 诺塞拉蒂奥的回答据说即使是进行泵送的操作，也是针对非常有限的未公开的 COM 特定消息集进行的。

BlockingCollection阻塞时确实会泵送。我在回答以下问题时了解到，其中有一些关于 STA 泵送的有趣细节：

StaTaskScheduler 和 STA 线程消息泵

然而，它将泵送非常有限的未公开的 COM 特定消息集，与您列出的其他 API 相同。它不会泵送通用 Win32 消息（特殊情况是WM_TIMER，也不会被发送）。对于某些需要全功能消息循环的 STA COM 对象来说，这可能是一个问题。

如果您想尝试一下，请创建您自己的版本SynchronizationContext, 覆盖SynchronizationContext.Wait, call SetWaitNotificationRequired并在 STA 线程上安装自定义同步上下文对象。然后在里面设置断点Wait并查看哪些 API 会使其被调用。

标准泵送行为在多大程度上WaitOne实际上是有限的吗？下面是导致 UI 线程死锁的典型示例。我在这里使用 WinForms，但同样的问题也适用于 WPF：

public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();

        this.Load += (s, e) =>
        {
            Func<Task> doAsync = async () =>
            {
                await Task.Delay(2000);
            };

            var task = doAsync();
            var handle = ((IAsyncResult)task).AsyncWaitHandle;

            var startTick = Environment.TickCount;
            handle.WaitOne(4000);
            MessageBox.Show("Lapse: " + (Environment.TickCount - startTick));
        };
    }
}

尽管任务只需要 2000 毫秒即可完成，但消息框将显示约 4000 毫秒的时间流逝。

发生这种情况是因为await继续回调通过安排WindowsFormsSynchronizationContext.Post，它使用Control.BeginInvoke，这又使用PostMessage，发布一条注册的常规 Windows 消息RegisterWindowMessage。此消息不会被推送，并且handle.WaitOne超时。

如果我们使用handle.WaitOne(Timeout.Infinite)，我们就会陷入经典的僵局。

现在让我们实现一个版本WaitOne具有显式泵送（并称其为WaitOneAndPump):

public static bool WaitOneAndPump(
    this WaitHandle handle, int millisecondsTimeout)
{
    var startTick = Environment.TickCount;
    var handles = new[] { handle.SafeWaitHandle.DangerousGetHandle() };

    while (true)
    {
        // wait for the handle or a message
        var timeout = (uint)(Timeout.Infinite == millisecondsTimeout ?
                Timeout.Infinite :
                Math.Max(0, millisecondsTimeout + 
                    startTick - Environment.TickCount));

        var result = MsgWaitForMultipleObjectsEx(
            1, handles,
            timeout,
            QS_ALLINPUT,
            MWMO_INPUTAVAILABLE);

        if (result == WAIT_OBJECT_0)
            return true; // handle signalled
        else if (result == WAIT_TIMEOUT)
            return false; // timed-out
        else if (result == WAIT_ABANDONED_0)
            throw new AbandonedMutexException(-1, handle);
        else if (result != WAIT_OBJECT_0 + 1)
            throw new InvalidOperationException();
        else
        {
            // a message is pending 
            if (timeout == 0)
                return false; // timed-out
            else
            {
                // do the pumping
                Application.DoEvents();
                // no more messages, raise Idle event
                Application.RaiseIdle(EventArgs.Empty);
            }
        }
    }
}

并把原来的代码改成这样：

var startTick = Environment.TickCount;
handle.WaitOneAndPump(4000);
MessageBox.Show("Lapse: " + (Environment.TickCount - startTick));

现在的时间间隔约为 2000 毫秒，因为await继续消息被泵送Application.DoEvents()，任务完成并且其句柄被发出信号。

也就是说，我绝不会建议使用类似的东西WaitOneAndPump用于生产代码（除了极少数的具体情况）。它是 UI 重入等各种问题的根源。这些问题是 Microsoft 将标准泵送行为限制为仅某些特定于 COM 的消息的原因，这对于 COM 封送至关重要。