线程安全GUI编程

Question

我用swing编程Java已经有几年了，并且一直认为GUI交互必须发生在事件调度线程上。最近，我开始为C应用程序使用GTK+，并且毫不奇怪地发现gtk_main必须调用GUI交互。类似地，我查看了SWT，看看Swing的不同之处，以及它是否值得使用，并且再次找到了UI线程的想法，我确信这3不是使用这个模型的唯一工具包。我想知道这种设计是否有什么原因，即将UI修改保持在单个线程上是什么原因。我可以理解为什么某些修改可能会导致问题(比如在绘制列表时修改列表)，但我不明白为什么这些问题会传递给API的用户。操作系统是否有限制？这些关注点没有“隐藏”(即用户不可见的某种形式的同步)有充分的理由吗？是否有任何(甚至纯粹是概念性的)创建线程安全图形库的方法，或者这样的事情实际上是不可能的？

我找到了这个http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness，它似乎与我理解它的方式不同(尽管我的理解和许多人的一样)，这与其他工具包有什么不同呢？是否可以在Swing中实现这个功能(因为EDT模型实际上并不阻止其他线程的访问，它通常只会导致异常)

Answer 1

与多个线程相比，单个活套线程更易于实现、理解和使用(例如单独的绘制器事件回调线程)。

因为在GUI中多线程，对GUI组件的所有访问都需要同步(只有例外是不可变的东西)，这将成为一个主要的瓶颈，特别是在获得锁或紧密耦合的框架中非常昂贵的时候。

此外，如果事件侦听器可以在任何线程上得到通知(无论哪个线程碰巧轮询事件队列)，那么需要将线程安全性应用到底层模型(这很难正确)。即使是上面的画图事件回调隔离示例，也需要读写同步。

需要注意的一点是，大多数框架都有用于长时间计算和IO (如SwingWorker)的后台线程的想法，或者至少有一种方法可以添加事件来调用事件线程上的某个函数(通常称为invoke)。

Answer 2

BeOS通过每个小部件单独的线程实现GUI，按照现代标准，它在非常原始的硬件上的响应性非常好(我注意到我的开发人员BeBox在使用dual 66 MHz Power 603和64 Mb内存时几乎没有延迟)。并发内存的安全性显然是一个主要问题，操作系统开发人员使用了许多不同的创新技巧来防止线程之间的内存冲突。这是一个很好的概述。