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

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

以下是引起我注意的文章的引用:

输入事件处理的问题在于它倾向于以与大多数GUI活动相反的方向运行.通常,GUI操作从一堆库抽象的顶部开始并"向下".我在我的应用程序中运行一个由一些GUI对象表示的抽象概念,所以我从我的应用程序开始,调用高级GUI抽象,调用较低级别的GUI抽象,调用丑陋的内容.工具包,然后进入操作系统.相比之下,输入事件从OS层开始,逐步向上调度抽象层,直到它们到达我的应用程序代码.

现在,由于我们使用抽象,我们自然会在每个抽象中单独进行锁定.不幸的是,我们有经典的锁定订单噩梦:我们有两种不同类型的活动,希望获得相反订单的锁定.所以僵局几乎是不可避免的.

Charlie Mart.. 7

不.即使作为一个经验法则,它只是简单地说"让它们起作用很难".但事件驱动的框架非常类似于事件驱动的模拟和其他各种事物; 事实上,Javaworld中的难点不是多线程的事实,而是Java中的抽象概念.

在另一个环境中,比如Erlang,它既相当自然,又非常强大.

更新

听起来他仍然有错误的抽象.我没有看到强制锁定问题的问题所固有的任何内容.我想,关键在于:

现在,由于我们使用抽象,我们自然会在每个抽象中单独进行锁定.不幸的是,我们有经典的锁定订单噩梦:我们有两种不同类型的活动,希望获得相反订单的锁定.所以僵局几乎是不可避免的.

那为什么僵局几乎不可避免呢？因为正在进行两种不同类型的活动,希望以相反的顺序获取锁.这是因为"我们自然会在每个抽象中单独锁定."

换句话说,他选择 - 或者是环境中为他选择的 - 抽象不支持他的需要.他似乎声称,因此没有任何抽象.我觉得这不令人信服.我首先检查两件事:

"很自然地,我们将在抽象中单独进行锁定",并且

"我们正在进行一些事件,希望以相反的顺序获得锁定."

根据我的经验,"自然X"通常意味着"我还没有真正寻找其他选择." 而且我非常怀疑这些事件是想要以相反的顺序获得锁定; 你得到一个锁,你做了什么,然后你释放它.

问题的关键是,他似乎提出,他认为要拿出一个方案,很难事实不工作,作为一个定理说,没有一个计划能正常工作.

如果没有关于这个问题的更多细节,很难构建一个反例,但正如我上面所说的那样,有很多系统的例子都是从内部流程和GUI管理的每个方向上异步进行的事件.拥有许多并发控制线程并且不会死锁.二郎神来到介意,因为一类这些问题,电话的,是这二郎神的发明之一,而事实上是问题的各种原因二郎被发明.

1> Charlie Mart..：

---

不.即使作为一个经验法则,它只是简单地说"让它们起作用很难".但事件驱动的框架非常类似于事件驱动的模拟和其他各种事物; 事实上,Javaworld中的难点不是多线程的事实,而是Java中的抽象概念.

在另一个环境中,比如Erlang,它既相当自然,又非常强大.

更新

听起来他仍然有错误的抽象.我没有看到强制锁定问题的问题所固有的任何内容.我想,关键在于:

现在,由于我们使用抽象,我们自然会在每个抽象中单独进行锁定.不幸的是,我们有经典的锁定订单噩梦:我们有两种不同类型的活动,希望获得相反订单的锁定.所以僵局几乎是不可避免的.

那为什么僵局几乎不可避免呢？因为正在进行两种不同类型的活动,希望以相反的顺序获取锁.这是因为"我们自然会在每个抽象中单独锁定."

换句话说,他选择 - 或者是环境中为他选择的 - 抽象不支持他的需要.他似乎声称,因此没有任何抽象.我觉得这不令人信服.我首先检查两件事:

"很自然地,我们将在抽象中单独进行锁定",并且

"我们正在进行一些事件,希望以相反的顺序获得锁定."

根据我的经验,"自然X"通常意味着"我还没有真正寻找其他选择." 而且我非常怀疑这些事件是想要以相反的顺序获得锁定; 你得到一个锁,你做了什么,然后你释放它.

问题的关键是,他似乎提出,他认为要拿出一个方案,很难事实不工作,作为一个定理说,没有一个计划能正常工作.

如果没有关于这个问题的更多细节,很难构建一个反例,但正如我上面所说的那样,有很多系统的例子都是从内部流程和GUI管理的每个方向上异步进行的事件.拥有许多并发控制线程并且不会死锁.二郎神来到介意,因为一类这些问题,电话的,是这二郎神的发明之一,而事实上是问题的各种原因二郎被发明.

---

@Gili,你仍然只能写一个答案.另一方面,你所说的是"同样的抽象并不是在Java中使用我想要的特定设置,所以所有多线程事件驱动的框架都难以处理."

2> Darren Clark..：

---

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

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

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