不使用 SendMessage() 从其他线程访问 UI 控件的原因？

Question

我读到 SendMessage() 不应该用于从其他线程访问 UI 控件，但我不确定我知道为什么，我能想到的唯一原因是因为 SendMessage() 是一个阻塞调用，那么在某些情况下它可能会导致死锁。

但这是不使用它的唯一原因吗？

---

编辑：这个article 谈到了不使用SendMessage() 的原因，但我觉得不是很清楚（它是为.NET 设计的）。

Answer 1

最好记住，您编写正确代码的几率不是很高。一般的建议是不要这样做！从不有必要，Windows 中 GUI 程序的 UI 线程完全是结构化的，可以让代码变得简单在另一个线程或进程内部运行会影响程序的 UI。消息循环的要点，producer-consumer problem的通用解决方案。 PostMessage() 是你利用它的武器。

在您继续前进之前，请先考虑一个使用 SendMessage 时很难解决的简单问题。如何安全正确地关闭窗户？

鉴于您需要关闭窗口的确切时间是完全不可预测的，并且与您的工作线程的执行完全不同步。是用户关闭它，或要求 UI 线程终止，您需要确保线程已退出并停止调用 SendMessage，然后才能真正关闭窗口。

执行此操作的直观方法是在 WM_CLOSE 消息处理程序中发出一个事件信号，要求线程停止。并等待它完成，然后窗口可以关闭。直观，但它不起作用，它会死锁你的程序。有时，并非总是如此，很难调试。当线程因为卡在 SendMessage 调用中而无法检查事件时出错。由于 UI 线程正在等待线程退出，因此无法完成。工作线程无法继续，UI 线程也无法继续。一个“致命的拥抱”，你的程序会挂起，需要强行杀死。死锁是一个标准的线程错误。

您会大喊：“我将使用 SendMessageTimeout！”但是你为 uTimeout 参数传递了什么，你如何解释一个 ERROR_TIMEOUT 错误？ UI 线程一段时间内紧张是很常见的，您肯定之前见过“幽灵窗口”，即在标题栏中显示“未响应”的窗口。因此 ERROR_TIMEOUT 并不能可靠地表明 UI 线程正在尝试关闭，除非您将 uTimeout 设置得非常大。至少 10 秒。这有点工作，但偶尔在出口处挂起 10 秒并不是很漂亮。

解决所有消息的此类问题，而不仅仅是 WM_CLOSE。 WM_PAINT 应该是下一个，另一个非常非常难以干净地解决的问题。您的工作线程要求在 UI 线程调用 EndPaint() 之前一毫秒更新显示。因此永远不会显示更新，它只会丢失。线程竞赛，另一个标准线程错误。

第三个经典的线程错误是 fire-hose 问题。当您的工作线程产生结果的速度快于 UI 线程可以处理它们时，就会发生这种情况。很常见，UI 更新非常昂贵。易于检测，很难解决，并且在发生时无法预测。易于检测，因为您的 UI 将冻结，UI 线程会消耗 100% 的内核以跟上消息速率。它不再处理它的低优先级任务。就像绘画一样。当您使用 SendMessage 或 PostMessage 时出错两者。在后一种情况下，您将把消息队列填满。它在包含 10000 条未处理的消息后开始失败。

长话短说，是的，SendMessage() 是线程安全的。但是线程安全不是传递属性，它不会自动使您自己的代码成为线程安全的。 所有当你使用线程时，你仍然会遇到可能出错的事情。死锁，比赛，灭火。害怕穿线的野兽。