Re: [Algorithms] General purpose task parallel threading approach

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

>Coroutines are an implementation of cooperative multi-tasking
Yes, it is basically a cooperative multitasking on top of a fixed number of
worker threads.

>As a last resort, you fall back on traditional synchronization primitives
if you can find no more efficient approach.
As far as I know this is the most common approach as well, because it is
less error prone. On the other side, in standard threads, or any job system
I've heard about, this approach is not efficient because it blocks the
execution thread.
What I propose here is a system where you can use traditional
synchronization primitives (as well as traditional way of io) without
blocking the worker thread. This is the main significant difference from
standard threads or job system because where one of them blocks (and makes
cpu idle) in case 2 of them enter synchronization primitive.

>I'm not quite sure what your library provides to the domain of game
development
That's what I would like your feedback on. I've come up with a very generic
way of utilizing cpu's at max regardless of the existence of synchronization
primitives or synchronous IO request. And I wonder what is missing here for
a game developer.

Regards,
Alexander.


2009/4/3 Tim Ambrogi <tim...@gm...>

> Alexander-
> Coroutines are an implementation of cooperative multi-tasking.  There are
> implementations in various dynamic languages, such as Lua and Stackless
> Python.  Also, there are less-portable implementations in C++ that involve
> inline assembly, setjmp/longjmp, fibers, etc... depending on the platform.
> See http://en.wikipedia.org/wiki/Coroutine for more info.
>
> It sounds, however, like you also want to write lower-level,
> performance-critical systems such as rendering, physics, serialization,
> etc... across many threads/cores.  Your library is similar in silhouette to
> the popular and fairly general job system, where you break down
> parallelizable tasks in N jobs that are tasked to idle threads.  These jobs
> aim to either minimize contention on shared resources, or operate in a
> wait-free manner on said resources.  If wait-free operation cannot be
> achieved within the domain, you usually try a lock-free approach that
> enables different threads to assist obstructing threads in completing their
> tasks while you wait.  As a last resort, you fall back on traditional
> synchronization primitives if you can find no more efficient approach.
>
> I'm not quite sure what your library provides to the domain of game
> development, but I'm sure it was motivated by a specific problem you
> encountered.  Perhaps you should describe your use cases more specifically,
> given that the stated domain of your library seems overly broad?
>
> --Tim A.
>
>
> On Fri, Apr 3, 2009 at 12:27 PM, <asy...@gm...> wrote:
>
>> What do you mean ?
>>
>> Alexander.
>>
>> 2009/4/3 Gregory Junker <gj...@da...>
>>
>>>   Isn’t this where coroutines come into play?
>>>
>>>
>>> Greg
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>