Re: [Algorithms] General purpose task parallel threading approach

[Jon W. <jw...@gm...>]

asy...@gm... wrote:
> To fight blocking conditions I've made a task suspension mechanics, 
> which allows a worker thread to suspend a task when it meets something 
> it should wait for (whether it is a mutex or an on going disk read). 
> After task is suspended, worker thread picks up another task from the 
> task pool, and keeps on executing it. When blocking condition ends, 
> task is resumed, and put back into a task pool.

You are basically combining fibers (co-operative threads) with 
pre-emptive threads. There really isn't that much cost difference 
between a pre-emptive thread and a fiber, so you might as well just 
spawn another pre-emptive thread, and suspend the current thread, rather 
than switching fiber on the current thread. If you're using a 
dynamically growing thread pool, your worst-case thread count (and thus 
memory usage) will be no worse than your worst-case fiber count.

>
>  - a unified way to wait on primitives (you can wait on all sort of 
> primitives including tasks together)
>  - task canceling
>  - timeout on wait operations

We do that in our fibers, too. However, it turns out that on most OS-es, 
you can do that for OS primitives too. On Windows, pretty much anything 
can go into WaitForMultipleObjects() (although there is a 64-object 
limitation). On UNIX, as long as something is a file descriptor, you can 
wait on it using select().

So, if instead of "suspending" the current "task" and picking another 
task within the worker thread -- which I presume to be exactly like 
fiber switching -- you instead just suspend the current thread and 
create a new thread in the thread pool, what would the difference be? 
Have you measured it?

Sincerely,

jw