The Synchronous Blog

Following the discussion from here and here…

Some problems arise from event-driven programming adoption:

1. Inversion of control:

Commanded by the environment, event-driven programs must quickly answer requests to keep the system up and running.
For instance, if a program wants to perform a time consuming operation (e.g. I/O), it must demand it to be done in the background and register a callback to continue the previous operations. If a logical sequence has three of these time consuming operations, the job must be separated into that many callbacks.
This characteristic leads to difficulty in visually understanding the applications’ control flow and is known as callback soup.

Another bad consequence of this code separation is that the state kept in callbacks are independent of each other as all local variables residing in their stacks are lost on returning. To keep state, their stacks must be manually reconstructed in the heap and passed as extra parameter from callback to callback.
This phenomenon is known as stack ripping.

In this sense, threads offer a more natural way of programming as the programmer may use the conventional sequential flow, keeping all state in thread’s single stack.

2. Multi-core processors:

Another issue with the event-driven approach is the challenge to take advantage of multi-core architectures.

In a common event-driven dispatcher, handlers must be run in sequence as they all share global state. When parallelized, two handlers would access the shared memory at the same time, leading to data corruption.

This is not the case with threads which are already artificially run in parallel even in single-core, thus having all shared memory protected manually with programmed instructions.
Well written multi-threaded programs take advantage of multi-core for free.

3. Listener life cycle:

Once a handler is registered for events it remains listening to them until a call to unregister is made.
In some sense, this is similar to manual memory management. The system is not capable of deciding by itself when a listener must be unregistered.
There is no such concept as “listen while some rule is valid”.

The first (and worst) problem is solved with cooperative multi-tasking.
A paper [1] explores this issue and shows this interesting graphic where the sweet spot is viewed as an improvement over both event-driven and multi-threading choices.

The second problem is a new one as multi-core architectures are still debuting.
I do have some ideas on this issue and believe that smarter people also do.
Giving different “colors” to unrelated callbacks is an option already in use [2].

The third problem arose on my own research and I’m searching for works to see if someone had already pointed that out. I’m working on a “listening scope” concept and wondered if something similar exists.

To conclude, I think that event-driven programming had always been seen more as technique than a true paradigm. Support in languages is very limited and always offered as a library layer that creates a small synchronous world for specific tasks.

[1] “Cooperative Task Management without Manual Stack Management”:
www.stanford.edu/class/cs240/readings/usenix2002-fibers.pdf
[2] “Multiprocessor Support for Event-Driven Programs”: people.csail.mit.edu/nickolai/papers/usenix2003-slides.pdf

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:
[1] “Event-driven programming for robust software” (pdos.csail.mit.edu/~rtm/papers/dabek:event.pdf)
[2] “Why Threads Are A Bad Idea (for most purposes)” (www.stanford.edu/class/cs240/readings/threads-bad-usenix96.pdf)
[3] “The Problem with Threads” (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf)
[4] “Why events are a bad idea for high-concurrency servers” (capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf)