For instance, many event systems “call” a method in another module by sending an event and expect a “return” from that method via a similar event mechanism. In order to understand the application, the programmer must mentally match these call/return pairs, even when they are in different parts of the code.
I somewhat disagree with this assessment. Just as there are different threading models, there are different event models. What the article describes is a pub/sub model of which I am not a big fan. I prefer an event observer model where an event as a very defined namespace and method signature or interface. Observers must conform to that interface to observe the event, therefore to find code relate to that event one only need look up what implements the events interface. I find that the way event based systems deal with control flow reduces a great deal of control flow programming which is where a lot of spaghetti gets implemented. Choosing the proper event model is just as important as choosing the correct threading model.
Event driven is very likely more reliable. It's also less intuitive, up to a point. But event driven systems can be very nearly deterministic.
It's nice to see preemptive multitasking given yet another black eye. If you really are interested in determinism and throughput, event driven probably yields the best results. But much of that is design discipline - in my opinion, for high reliability, use cases by message sequence chart is certainly up there as a paradigm. It's much easier to audit for "correctness" ( and so long as you completely enumerate all preconditions, it gets asymptotically close to correct behavior ). One could do worse than a Rhapsody approach to design, even if you don't generate code from it.
This being said, I can see how threading might be a better choice for rich multiprocessor systems, if one can design a cache regime to take advantage of the location of state.
I somewhat disagree with this assessment. Just as there are different threading models, there are different event models. What the article describes is a pub/sub model of which I am not a big fan. I prefer an event observer model where an event as a very defined namespace and method signature or interface. Observers must conform to that interface to observe the event, therefore to find code relate to that event one only need look up what implements the events interface. I find that the way event based systems deal with control flow reduces a great deal of control flow programming which is where a lot of spaghetti gets implemented. Choosing the proper event model is just as important as choosing the correct threading model.