http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html认为多线程 GUI 框架是一个失败的梦想。非 GUI 框架怎么样？这个经验法则是否适用于所有事件驱动框架？
这是引起我注意的文章中的一句话：
输入事件处理的问题在于它往往以与大多数 GUI 活动相反的方向运行。一般来说，GUI 操作从库抽象堆栈的顶部开始，然后“向下”进行。我在我的应用程序中操作一个由一些 GUI 对象表达的抽象概念，因此我在我的应用程序中开始并调用高级 GUI 抽象，这些抽象调用了较低级别的 GUI 抽象，这些抽象调用了丑陋的内部结构。工具包，然后进入操作系统。相比之下，输入事件从操作系统层开始，并逐渐“向上”分派到抽象层，直到它们到达我的应用程序代码。
现在，由于我们正在使用抽象，我们自然会在每个抽象中单独进行锁定。不幸的是，我们遇到了经典的锁排序噩梦：我们有两种不同类型的活动正在进行，它们想要以相反的顺序获取锁。所以僵局几乎是不可避免的。
不。即使作为经验法则，它也只是说“很难让它们发挥作用”。但事件驱动框架非常类似于事件驱动模拟和其他各种东西；事实上，Java 世界中的困难并不是因为多线程，而是因为 Java 中可用的抽象。
在另一个环境中，比如 Erlang，它既相当自然，又非常健壮。
Update
听起来他的抽象概念仍然是错误的。我没有看到该问题中存在任何强制锁定问题的固有问题。我认为关键在这里：
现在，由于我们正在使用抽象，
我们自然会进行锁定
在每个抽象中分别进行。
不幸的是我们有经典
锁排序噩梦：我们有两个
正在进行不同类型的活动
想要获取相反的锁
命令。所以僵局差不多了
不可避免的。
那么为什么僵局几乎不可避免呢？因为正在发生两种不同类型的活动，它们想要以相反的顺序获取锁。这是因为“我们自然会在每个抽象中单独进行锁定”。
换句话说，他选择了——或者环境为他选择了——不支持他的需求的抽象。他似乎声称，因此不存在这样的抽象。我觉得这没有说服力。我首先要检查两件事：
- "自然我们将在抽象中单独进行锁定”，并且
- “我们正在发生一些事件，希望以相反的顺序获取锁。”
根据我的经验，“自然 X”通常意味着“我还没有真正寻找其他选择”。我非常怀疑事件想要以相反的顺序获取锁；你获得了一个锁，你做了一些事情，然后你释放了它。
关键是，他似乎在陈述这样一个事实：他发现很难想出一个计划来does作为一个定理来说明没有方案can work.
如果没有关于问题的更多细节，就很难构造一个反例，但正如我上面所说，有很多系统示例，这些系统的事件以各种方式异步地从内部进程和 GUI 进行，这些系统管理有许多并发控制线程并且不会死锁。我想到了 Erlang，因为这些问题中的一类——电话——是 Erlang 的发明对象，事实上，这些问题是whyErlang 被发明了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
