Intel Threading Building Blocks

Think Tasks, Not Threads

You should think about game architecture in terms of tasks rather than threads. Each task should have several characteristics:

Parallel

A task is a unit of work that is done repetitively and can be done independently.

Managed

At the end of task execution, normally it will be recreated as a task in the next frame of work. A leaf- or object-level task should not create other tasks.

Autonomous

The task should minimize synchronization with tasks on other threads. If a synchronization lock is needed between tasks, the locked region should be as small as possible. At runtime, if the same thread releases and claims a lock, it is not-good overhead compared to serial code. Or if one thread releases it and, after some delay (this is an uncontended lock), the next thread claims it, it is also not-good. It is bad only if the lock is contended, such as when multiple threads are simultaneously interfering to get the lock. You can use the Intel Thread Profiler to measure this directly, which is how you can go about characterizing your own usage.

In the physics interaction set of tasks, we want to create tasks so that:

• There are several times more tasks than threads to allow task stealing for load balancing. (See the next section, “Load Balancing Versus Task Stealing.”)

• Tasks that are close to each other in game space where they might communicate get scheduled on the same thread to maximize the opportunity for cache reuse and local synchronization.

The latter is achieved by using ...