The future of concurrent programming

[Pragma]

Robert Fraser wrote:
> Henrik Wrote:
> 
>> Todays rant on Slashdot is about parallel programming and why the
> ... [snip]
> 
> At work, I'm using SEDA:
> 
> http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf

Wow.

Anyone doubting if this makes a difference should compare the graphs on pages 18 and 25.

> 
> Although it's designed primarily for internet services (and indeed, I'm crafting an internet service...), I'm using
> it for a lot more than just the server portions of the program, and I plan to use it in future (non-internet-based)
> solutions.
> 
> The general idea behind something like this is "fire and forget". There is a set of "stages", each with a queue of
> events, and a thread pool varying in size depending on load (all managed behind the scenes). The creator of a stage
> needs only to receive an event and process it, possibly (usually), pushing other events onto other stages, where they
> will be executed when there's time. Stages are highly modular, and tend to serve only one, or a small group of,
> functions, but each stage is managed behind the scenes with monitoring tools that increase and decrease thread count
> respective to thread load.
> 
> The advantage of such a system is it allows the designer to think in a very "single-threaded" mindset. You deal with
> a single event, and when you're done processing it, you let someone else (or a few other people) deal with the
> results. It also encourages encapsulation and modularity.
> 
> The disadvantage? It's not suited for all types of software. It's ideal for server solutions, and I could see its use
> in various GUI apps, but it might be hard to force an event-driven model onto something like a game.

Actually, just about everything in most modern 3d games is event driven, except for the renderer. FWIW, the renderer 
simply redraws the screen on a zen timer, based on what's sitting in the render queue, so it can easily be run in 
parallel with the event pump.  The event pump, in turn, modifies the render queue.

The only difference between a game and a typical GUI app is that even modest event latency can be a showstopper.  The 
renderer *must* run on time (or else you drop frames), I/O events must be handled quickly (sluggish handling), 
game/entity events must be fast, and render queue contention must be kept very low.

> 
> Combined with something like the futures paradigm, though, I can see this being very helpful for allowing
> multi-threaded code to be written like single-threaded code.
> 
> Now only to port it to D...


-- 
- EricAnderton at yahoo