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.
I would have to say no, with a caveat. Event driven frameworks that revolve around shared state, such as a UI, should be single threaded. Event driven frameworks that revolve around notifications, such mechanical monitoring(e.g. letting you know when the pressure in a pipe is too high), could be single threaded, but might be more appropriate to be multi threaded.
It is certainly possible to build a multi threaded UI framework, and I have done so myself. In the end I converted it to be single threaded. Part of the reason does fall under what Charlie said about ‘it’s too hard’. The problem was that with a multi-threaded UI framework, it wasn’t just me that had to deal with the threading, but anyone that used the UI. The core was certainly thread safe, but then anyone that wrote a control had to make that thread safe as well. Nevermind that when making multiple changes to the UI, you had to notify the core that you were doing so so you didn’t get partial updates. Since a user is generally a pretty slow thing, any performance gain was really negligible, and could be worked around with an asynchronous call if necessary for specific cases. Single threading is actually the appropriate model here.
On the other hand, in a model where there isn’t(or isn’t much) shared state, a multi threaded model makes eminent sense. There’s no reason for one event(the reactor is on fire) to be delayed for the 30 seconds it takes for your query(Bob the operator just clocked out) to timeout because some yahoo in operations left the punch_card table locked.