Re: [Boost-users] boost::threads is it all about managed threads?

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-03-11 16:54:39

On Thu, 3 Mar 2005 23:19:52 -0800, The Grumpiest Man You Know
<mrgrumpyguts_at_[hidden]> wrote:
> I think that sounds like a job for
> threads;  no need to alter the service code, just replace the routine
> that returns the results and bob's your mum's brother and I can get 10
> at a time all sleeping waiting for the requested IO.  But to not scare
> the natives I'd prefer to have a single thread unless the load
> actually demands more.
>
> Now, my old C brain can see that the main thread can get it's thread
> ID from thread_self() and then just be one of the guys but I can't see
> how the boost::thread() can do anything but give me threads to manage.
>  After stepping on myself with a vector<boost::thread> :) I think this
> is the tao of boost::thread:
> 
>   const boost::function0<void> run = &go;
>   boost::thread_group grp;
> 
>   for(int i = 0; i < 100; i++) {
>     grp.create_thread(go);
>   }
> 
>   grp.join_all();
> 
> Is that right?  What am I missing?  How do I get a bunch of peer boost::threads?

This looks fine to me.

I'd just suggest as a general design not stopping and starting threads
with any great frequency (which is what you seem to suggest at the end
of the first quoted para).  Leave your threads running all the time,
but use some sort of synchronized queue to pass them work to process
(and perhaps a second queue to get results back).  If all threads are
busy the requests will start to back up in the queue, but when the
queue is empty, all of the threads will block waiting for data, and
this will use very little in the way of system resources.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com