.NET UI 元素线程限制的原因

Question

我们知道，除了实例化元素的线程之外，不可能从任何线程执行操作任何 UI 元素属性的代码......我的问题是：为什么？

我记得当我们使用 COM 用户界面元素时（在 COM/Visual Basic 6.0 时代），所有 UI 元素都是使用 COM 类和 co-class 创建的，它们使用称为 Thread- 的内存模型存储其资源 -本地存储 (TLS)，但我记得，这是必需的，因为与 COM 组件的构造方式相关，并且不应该与 .NET UI 元素相关。这种限制仍然存在的根本原因是什么？

是因为底层操作系统仍然对所有 UI 元素使用基于 COM 的 Win32 API 类，即使是在托管 .NET 应用程序中操作的那些？

Answer 1

AFAIK，它甚至比 COM 更基本。它归结为良好的 ol' Windows API。我相信 Windows 中的窗口应该由一个线程拥有，期间。每个线程都有自己的消息泵，将消息分派到它拥有的窗口。它是 Windows 的一个非常基本的构造——现在可能有点过时，但很基本。

我的感觉是，当您需要将 WPF 集成到 Windows 窗体应用程序中，或者如果您需要使用您在某个地方获得的 HWND 与应用程序中的其他地方的 Windows 对象进行猴子操作时，这种线程关联有助于互操作性。 . 这可能也是允许旧版本的 Windows (XP) 托管 WPF 应用程序而无需对操作系统本身进行任何重大架构更改的原因。

Answer 2

听起来您指的是 WPF，而不是通用的 Windows API 编程。我不是 WPF 内部的专家，但这里有一些关于为什么将 UI 操作保留在一个 UI 线程中是一个好主意的内容：

1. 避免死锁。当您有多个线程在运行时，所有共享资源都必须受到某种锁的保护。当有多个锁时，陷入死锁的风险很高 - 线程 A 拥有锁 1 但正在等待锁 2，线程 B 拥有锁 2 但正在等待锁 1。这可以通过严格的顺序来避免锁定获取，但人性不足。
2. 减少对昂贵锁的需求。如果您可以要求所有 UI 操作在 UI 线程上执行，则可以消除保护内部数据所需的大量锁。
3. 降低创建由没有消息循环的线程拥有的窗口句柄的风险。

最后一项与 Win API 相关。创建窗口句柄时，它会绑定到发出 CreateWindow 调用的线程。发送到该窗口句柄的消息将被放置在与该线程关联的消息队列中。如果该线程不处理窗口消息，则窗口将无响应 - UI 冻结。如果另一个线程尝试向该窗口发送消息，则该线程也将被冻结，等待同步调用完成。这雪球很快就变得丑陋了。这就是为什么确保只在准备处理窗口消息的线程上创建窗口句柄很重要的原因。

为什么窗口句柄的消息队列绑定到特定线程？我不知道，但我相信答案不是微不足道的。

Answer 3

来自http://msdn.microsoft.com/en-us/library/ms741870.aspx：

从历史上看，Windows 允许 UI 元素只能由 创建它们的线程。这意味着 一个后台线程负责 一些长时间运行的任务无法更新 完成后的文本框。视窗 这样做是为了确保完整性 用户界面组件。一个列表框可能看起来 奇怪，如果它的内容被更新了 在后台线程 绘画。