multithreading - 所有事件驱动的框架都应该是单线程的吗？

Question

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html认为多线程GUI框架是一个失败的梦想。非GUI框架又如何呢？这个经验法则是否扩展到所有事件驱动的框架？

这是引文引起我注意的引文:

The problem of input event processing is that it tends to run in the opposite direction to most GUI activity. In general, GUI operations start at the top of a stack of library abstractions and go "down". I am operating on an abstract idea in my application that is expressed by some GUI objects, so I start off in my application and call into high-level GUI abstractions, that call into lower level GUI abstractions, that call into the ugly guts of the toolkit, and thence into the OS. In contrast, input events start of at the OS layer and are progressively dispatched "up" the abstraction layers, until they arrive in my application code.

Now, since we are using abstractions, we will naturally be doing locking separately within each abstraction. And unfortunately we have the classic lock ordering nightmare: we have two different kinds of activities going on that want to acquire locks in opposite orders. So deadlock is almost inevitable.

Answer 1

请注意，我不得不拒绝。围绕共享状态的事件驱动框架(例如UI)应该是单线程的。以通知为中心的事件驱动框架，例如机械监视(例如让您知道管道中的压力何时过高)，可以是单线程的，但更适合于多线程的。

当然，可以构建一个多线程的UI框架，而我本人也是这样做的。最后，我将其转换为单线程。部分原因确实属于查理所说的“太难了”。问题在于，使用多线程的UI框架，不仅需要处理线程的人，还包括使用UI的任何人。核心当然是线程安全的，但是随后编写控件的任何人也必须使该线程安全。没关系，当对UI进行多次更改时，您必须通知内核您正在执行此操作，这样您就不会得到部分更新。由于用户通常是一件很慢的事情，因此任何性能提升实际上都可以忽略不计，并且在特定情况下必要时可以通过异步调用解决。单线程实际上是这里合适的模型。

另一方面，在没有(或没有太多)共享状态的模型中，多线程模型非常有意义。没有理由将一个事件( react 堆着火了)延迟查询所需要的30秒(鲍勃，运算符(operator)刚退出时钟)超时，因为某些yahoo操作使punch_card表锁定了。