Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

Without the ability to save/restore tasks your dependency system will have a
big bunch of limitations, because you can only execute tasks during a wait
in a recursive way ONLY.

2009/4/5 Jarkko Lempiainen <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
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Regards,
Alexander Karnakov