The Synchronous Blog

A blog about reactive programming languages.

“Cada Macaco no seu Galho”

with 3 comments

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)” (http://www.stanford.edu/class/cs240/readings/threads-bad-usenix96.pdf)
[3] “The Problem with Threads” (http://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)

Advertisements

Written by francisco

August 21, 2008 at 1:42 pm

3 Responses

Subscribe to comments with RSS.

  1. You’re right, man.
    I personally prefer building a monothreaded application with a robust finite state machine (main loop), than relying on system threads and monitors. The problem is that the code just does not look “synchronized”, in a logical way.
    If LuaGravity achieves to provide a clear logical syntax for synchronization, while built on a simple, reliable backend, I have no doubt it will be very useful.

    Alexandre

    August 26, 2008 at 8:25 pm

  2. I’m preparing a post on “The problems with Events” to summarize its drawbacks.
    As you mentioned, we lack good “control structures” for synchronized code.
    LuaGravity does have support for it as I’ll show with its imperative features.
    Thanks for your thoughts.

    francisco

    August 26, 2008 at 9:02 pm

  3. […] The problem with Events Following the discussion from here and here… […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: