Now posting at

July 17, 2014

Where I post now is over at

Refactoring for Task Concurrency

February 3, 2011

This is really more of a follow on from my previous article, Preparing for Parallelism. Some of the comments wanted more explanation, and an example of what I actually mean about the likes of incorrect data and controlling execution context.

What I explained was a tips for a component/entity system, a task based one: concurrent systems, running in parallel, and communicating effectively between each other.  Fine-grained parallelism does not apply. I also mentioned the fact that being able to accept, and properly deal with out of date ‘incorrect’ data can lead to some novel opportunities for parallelism.

Not to say the methods I employ lead to perfect parallelism and scalability, I do believe they allow for implementing a level of concurrent operation in a cost-effective manner on current hardware, without the hidden quirks that locks can have creep up on your frame profile. I include ‘lock-free algorithms’ in that, as those can cause nasty contention issues. If you disagree, please comment, as I’m really interested in hearing other opinions and experiences on the matter.

First of all, what changes are those that really make concurrent execution hard, even if you allow for reading data which is possibly a frame out of date?

You can read the full article over at



Preparing for Parallelism

January 19, 2011

Don’t worry, just parallelize everything and have it run over all the cores.

Ouch. This is going to hurt. Invariably it does; when you end up having that really hard to find heap corruption issue, or when those odd pauses creep into the profiler when calling into that middleware. Parallel execution is tough at the best of times, and I think it is harder in gamecode where the notion of a game-frame is key. Something I have learned over the years looking at codebases is that many developers do very little groundwork in preparation for parallel operation. Laying some clear code foundations and keeping to a small set of rules can result in less pain encountered in the long term.  In this post, I’m going to share the main tips/rules I try to abide by when doing that job; something I find myself doing often to increase the prospect of allowing more parallelism.

These tips allow designing systems for parallel execution simpler, but it is still not easy street. You need deep knowledge of the systems you are working with, the data it touches, and above all understand what makes things inherently serial. Also you need to understand how you are going to achieve the parallelism; are you using multiple threads running over multiple jobs, running a large subsystem for the most part of a frame, or are you going to use the SPUs?

You can read the whole post over at, where I am a contributor.