Re: [Algorithms] General purpose task parallel threading approach

[Jarkko L. <al...@gm...>]

You could also not have a wait for dependent tasks within a task, but rather
have job queue dependency system to take care of it by splitting the
function in two tasks. Or you could implement the wait by pulling tasks from
the job queue until the dependent tasks have been completed. There is no
context switches needed in either case though.

 

  _____  

From: Sebastian Sylvan [mailto:seb...@gm...] 
Sent: Sunday, April 05, 2009 3:31 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

 

On Sun, Apr 5, 2009 at 1:10 AM, Jarkko Lempiainen <al...@gm...> wrote:

I think you really need to target for both task and data level parallelism
to make your game engine truly scalable for many-core architectures. I don't
see why you would need to consider the cost of context switching in relation
to const of a task execution though since if you got a job queue, each
worker thread just pulls tasks from the queue without switching context.

 

The problem is when you have a task spawn N other tasks and then wait for
their results, the core running that worker needs to do something until the
two sub-tasks have completed. In practice, I do think that this kind of
synchronisation (specifically the fork-and-join model) will be extremely
common in the future, which means that context switch needs to be fast
(Windows 7's user mode scheduling may be useful here - in fact I believe
that's what Microsoft's native concurrency runtime uses, while the .Net one
is backed by thread pools, I believe).

 



-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862