Re: [Algorithms] General purpose task parallel threading approach

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

>Lock-free algorithms are, in some ways, less error-prone.
I'm not an expert in lock-free for sure, but most advanced lock-free
structure I've seen was a double linked list implementation. In many
real-life scenarios you often need to keep consistent a lot more complex
structures (i.e. - a set of some tables, like hashmaps), for which I think
it would be close to impossible to write an efficient lock free
implementation.

I also noticed that most programmers prefer using mutexes anyway, because it
is easier to write, clear to other programmers what happens, and guaranteed
to work. This made me thinking that using mutexes is fine as far as you
provide a cheap way for cpu to execute something else while mutex is being
hold.

>How does the library you wrote solve the specific problems you encountered?
Originally I was trying to solve the problem of how to write a server,
serving multiple clients simultaneously utilizing all cores without writing
a state machine for each client (I found out that it is damn complex to
extend logic when it is expressed via state machine).
The solution I have now perfectly fits imho - I only need to write a task
per client which does simple send/receive (as if you'd write a single
threaded application), and I get ideal multicore scale.

Regards,
Alexander.

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

> On Fri, Apr 3, 2009 at 10:55 PM, <asy...@gm...> wrote:
>>
>> 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.
>
>
> Lock-free algorithms are, in some ways, less error-prone.  In particular,
> correctly-implemented lock-free algorithms cannot deadlock, and prevent
> priority inversion.
>
>
>> >I'm not quite sure what your library provides to the domain of game
>> development
>> That's what I would like your feedback on.
>
>
> In that case, I again suggest you provide some specific use cases.  What
> problems did you run into that led you to write the library?  How does the
> library you wrote solve the specific problems you encountered?
>
> --Tim A.
>
>
>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>



-- 
Regards,
Alexander Karnakov