为什么在 UI 线程上输入锁会触发 OnPaint 事件？

Question

我遇到了一些我完全不明白的事情。 在我的应用程序中，我有几个线程都将项目添加（和删除）到共享集合（使用共享锁）。 UI 线程使用一个计时器，并且在每个滴答声中它使用集合来更新它的 UI。

由于我们不希望 UI 线程长时间持有锁而阻塞其他线程，所以我们这样做的方式是，首先获取锁，复制集合，然后释放锁定，然后处理我们的副本。 代码如下所示：

public void GUIRefresh()
{
    ///...
    List<Item> tmpList;
    lock (Locker)
    {
         tmpList = SharedList.ToList();
    }
    // Update the datagrid using the tmp list.
}

虽然它运行良好，但我们注意到有时应用程序会变慢，当我们设法捕获堆栈跟踪时，我们看到了：

....
at System.Windows.Forms.DataGrid.OnPaint(PaintEventArgs pe)
at MyDataGrid.OnPaint(PaintEventArgs pe)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Threading.Monitor.Enter(Object obj)
at MyApplication.GuiRefresh()   
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
....

请注意，输入锁 (Monitor.Enter) 之后是 NativeWindow.Callback，它会导致 OnPaint。

• 这怎么可能？ UI 线程是否被劫持以检查其消息泵？那有意义吗？还是这里有别的东西？

• 有没有办法避免它？我不希望从锁中调用 OnPaint。

谢谢。

Answer 1

GUI 应用程序的主线程是一个 STA 线程，即单线程单元。请注意程序的 Main() 方法上的 [STAThread] 属性。 STA 是一个 COM 术语，它为从根本上是线程不安全的组件提供了一个好客的家，允许从工作线程调用它们。 COM 在 .NET 应用程序中仍然非常活跃。拖放、剪贴板、外壳对话框（如 OpenFileDialog）和常用控件（如 WebBrowser）都是单线程 COM 对象。 STA 是 UI 线程的硬性要求。

STA 线程的行为约定是它必须泵送消息循环并且不允许阻塞。阻塞很可能导致死锁，因为它不允许这些单元线程 COM 组件的编组继续进行。您正在使用 lock 语句阻塞线程。

CLR 非常了解该要求并对此采取了一些措施。像 Monitor.Enter()、WaitHandle.WaitOne/Any() 或 Thread.Join() 这样的阻塞调用会导致消息循环。执行此操作的本地 Windows API 类型是 MsgWaitForMultipleObjects(). 该消息循环调度 Windows 消息以保持 STA 活动，包括绘制消息。当然，这可能会导致重入问题，Paint 应该不是问题。

Chris Brumme blog post 中有很好的背景资料。

也许这一切都敲响了警钟，您可能不禁注意到这听起来很像一个调用 Application.DoEvents() 的应用程序。可能是解决 UI 冻结问题的最可怕的方法。对于幕后发生的事情，这是一个非常准确的心智模型，DoEvents() 还泵送消息循环。唯一的区别是，CLR 的等效项对于允许分派的消息更具选择性，它会过滤它们。与分派所有内容的 DoEvents() 不同。不幸的是，Brumme 的帖子和 SSCLI20 的源代码都没有足够详细，无法准确知道正在调度什么，执行此操作的实际 CLR 函数在源代码中不可用，而且太大而无法反编译。但很明显，您可以看到它不过滤 WM_PAINT。它将过滤真正的麻烦制造者，输入事件通知，例如允许用户关闭窗口或单击按钮的那种。

功能，而不是错误。通过消除阻塞和依赖编组回调来避免重入问题。 BackgroundWorker.RunWorkerCompleted 就是一个经典的例子。

Answer 2

好问题！

.NET 中的所有等待都是“可提醒的”。这意味着如果等待阻塞，Windows 可以在等待堆栈的顶部运行“异步过程调用”。这可以包括处理一些 Windows 消息。我没有专门尝试过 WM_PAINT，但根据你的观察，我猜它是包括在内的。

一些 MSDN 链接：

Wait Functions

Asynchronous Procedure Calls

Joe Duffy 的《Windows 上的并发编程》一书也涵盖了这一点。

Answer 3

我在遇到等待句柄阻塞问题时发现了这个问题。对此的回答给了我下一步实施的提示：

 public static class NativeMethods
{
    [DllImport("kernel32.dll", SetLastError = true)]
    internal static extern UInt32 WaitForSingleObject(SafeWaitHandle hHandle, UInt32 dwMilliseconds);
}

public static class WaitHandleExtensions
{
    const UInt32 INFINITE = 0xFFFFFFFF;
    const UInt32 WAIT_ABANDONED = 0x00000080;
    const UInt32 WAIT_OBJECT_0 = 0x00000000;
    const UInt32 WAIT_TIMEOUT = 0x00000102;
    const UInt32 WAIT_FAILED = INFINITE;

    /// <summary>
    /// Waits preventing an I/O completion routine or an APC for execution by the waiting thread (unlike default `alertable`  .NET wait). E.g. prevents STA message pump in background. 
    /// </summary>
    /// <returns></returns>
    /// <seealso cref="http://stackoverflow.com/questions/8431221/why-did-entering-a-lock-on-a-ui-thread-trigger-an-onpaint-event">
    /// Why did entering a lock on a UI thread trigger an OnPaint event?
    /// </seealso>
    public static bool WaitOneNonAlertable(this WaitHandle current, int millisecondsTimeout)
    {
        if (millisecondsTimeout < -1)
            throw new ArgumentOutOfRangeException("millisecondsTimeout", millisecondsTimeout, "Bad wait timeout");
        uint ret = NativeMethods.WaitForSingleObject(current.SafeWaitHandle, (UInt32)millisecondsTimeout);
        switch (ret)
        {
            case WAIT_OBJECT_0:
                return true;
            case WAIT_TIMEOUT:
                return false;
            case WAIT_ABANDONED:
                throw new AbandonedMutexException();
            case WAIT_FAILED:
                throw new System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error());
            default:
                return false;
        }
    }
}