Should all event-driven frameworks be single-threaded?

Question

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html argues that multithreaded GUI frameworks are a failed dream. What about non-GUI frameworks? Does this rule of thumb extend to all event-driven frameworks?

Here is a quote from the article that caught my attention:

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

No. Even as a rule of thumb, it's simply saying "it's hard to make them work." But event-driven frameworks are very much like event-driven simulation and various other things; the fact that it's hard in Javaworld isn't a fact about multithreading, but about the abstractions available in Java.

In another environment, like Erlang, it's both fairly natural, are pretty robust.

Update

It still sounds like he has the wrong abstractions. I don't see anything inherent in the problem that forces a locking issue. The key, I think, come in here:

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.

So why is deadlock almost inevitable? Because two different kinds of activities are going on that want to acquire locks in opposite orders. And that is because "we will naturally be doing locking separately within each abstractions."

In other words, he's chosen -- or had chosen for him by the environment -- abstractions that don't support his needs. It follows, he appears to claim, that thus there are no abstractions that would. I don't find this convincing. I'd start by examining two things:

• "naturally we will be doing locking separately within abstractions", and
• "we have events going on that want to acquire locks in opposite orders."

In my experience, "naturally X" usually means "I haven't really looked for other options." And I very much doubt that the events want to acquire locks in opposite orders; yu get a lock, you do something, and you release it.

The point is, he appears to be presenting the fact that he finds it hard to come up with a scheme that does work as a theorem to say that no scheme can work.

Without a lot more details about the problem, it's hard to construct a counter-example, but as I said above, there are lots of examples of systems that have events going on every which way, asynchronously, from internal processes and GUIs, that manage to have many concurrent threads of control and don't deadlock. Erlang came to mind because one class of those problems, telephony, is the one for which Erlang was invented, and in fact those sorts of issues are why Erlang was invented.