“Cada Macaco no seu Galho”
Or “A place for everything and everything in its place”.
In applications like games and multimedia systems several entities run concurrently, leading to a high degree of internal and external interactivity among them.
Internal entities might be game characters, graphical widgets, AI actions and so on, while external entities might be the mouse, keyboard, network and also the time.
Interaction may be better defined as synchronization in this scope.
Using a shooter game as an example, a character movement is synchronized with user controls, as a gun sight is with the mouse position. Also, animations must be synchronized, so that all objects move together.
Currently, when realizing that asynchronous threads are not adequate for these applications, most programmers use event-driven or observer pattern techniques (I’ll use the general term implicit invocation).
Synchronous functionality is present in some conventional languages, unfortunately they are barely used when known.
Continuations or coroutines are examples of such features present in languages like Scheme and Lua.
With coroutines, the programmer can keep state between successive calls to the same callback and avoid issues in implicit invocation such as inversion-of-control and stack-ripping.
It’s not by chance that Lua is so popular in the game industry.
A place is still reserved for asynchronous threads: exactly where you don’t need a high degree of synchronization.
If you want to compute the product of some 1000×1000 matrices, there’s no point on doing it synchronized, just go async.
You can still have some degree of synchronization, though. That would be in specific (and obvious) points like a memoization table for calculated results.
Well, this is only an opinion, still in the need for a more solid background.
I would like to see more papers around this topic, although it’s not easy to find bibliography defending asynchronous threads.
Maybe their advocates are just indifferent to this discussion or too busy debugging their applications.
What do you think?
Here is some bibliography:
 “Event-driven programming for robust software” (pdos.csail.mit.edu/~rtm/papers/dabek:event.pdf)
 “Why Threads Are A Bad Idea (for most purposes)” (http://www.stanford.edu/class/cs240/readings/threads-bad-usenix96.pdf)
 “The Problem with Threads” (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf)
 “Why events are a bad idea for high-concurrency servers” (capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf)