Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-11-02 11:17:10

> > > The idea behind using fiber inside a threadpool is, that each
> > > worker-thread executes multiple fibers - fiber would yield its
> execution
> > > if future::get() would block (because future is not ready)
> >
> > Exactly. That's what my prototype does too. My point is that you can
> > do this without fibers too, but you might run out of stack.
> 
> Interessting - I'd like to see how the code works. Is it possible to
> access
> your prototype?
> 
> > One thing you can do with fibers that you can't easily do with a
> > single stack is switch back to the parent task when the nested task
> > blocks. Doing so allows you to run *other* tasks from the pool if a
> > thread blocks and the task it is waiting for is already running
> > elsewhere. You can also migrate tasks between threads.
> 
> That's the way boost.threadpool uses boost.fiber (but fibers are not
> exchanged
> between worker-threads -> work-stealing is done only on un-fibered
> tasks
> waiting in the local queue of a worker-thread).

IMHO, work stealing is independent from moving tasks between threads. Work
stealing is a specific way of scheduling, while moving tasks between threads
is a matter of resource allocation.

For instance we have a simple one queue round robin fiber scheduler with
several threads picking up the next available task. It's built on top of a
lock-free queue and doesn't involve any explicit locking at all. If yielded
for some reason tasks get re-scheduled (reinserted into the queue). That's
very fast and powerful, and I don't know if it's easy to implement without
fibers.

Regards Hartmut