Re: Task groups using boost::thread

From: gunnarnl (gunnar_at_[hidden])
Date: 2002-03-20 17:50:04

--- In Boost-Users_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> 
> It sounds to me like what you want isn't a thread_group, but a 
> thread_pool.  All the thread_group is is a convenient way to manage 
> the lifetime of multiple threads.  A thread_pool, on the other 
hand, 
> not only manages the lifetime but also the operation of the 
threads.  
> With a thread_pool you simply add jobs and the thread_pool 
dispatches 
> the job to a running thread if it's available, possibly spawns a 
new 
> thread if there isn't an available thread, or adds the job to a 
queue 
> to be processed by the next available thread.  Elaborate thread 
pools 
> allow you to control things like the minimum and maximum number of 
> threads that will be spawned to handle the jobs and how long a 
thread 
> should be allowed to sit idle waiting for another job before it 
self 
> terminates.
> 
> There are plans to add a thread_pool to Boost.Threads.  In fact, a 
> prototype is nearly ready to be uploaded to the main Boost list for 
> comments (it's actually being worked on by someone else, but I've 
had 
> some input on it).
> 

Yes, it sounds exactly what I want. When will it be available?

> 
> This looks more like the classic example of the usage of 
> thread_group, leaving me to wonder precisely what it is you want to 
> accomplish.  This code doesn't illustrate capping the number 
> of "tasks", for instance.  It's also a bit more complex then what I 
> would have done, though it does work.
> 

Ah well, it was just a test for the thread group anyway. It was just 
an idea of having some type of a life-cycle of a task, i.e. in this 
case setup, run and cleanup. Tasks would be forced to follow this 
strategy.

> > By the way, is there an operation in boost::thread to get the 
> current 
> > thread id?
> 
> No, because not all platforms have any concept of thread id.  I may 
> add something along these lines soon, though it won't be precisely 
> what you expect, I think.  The ID won't be an integer, though it 
will 
> be comparable.
> 

That's right. I guess though, it will be enough if I could identify 
the thread_pools, mainly for logging I presume.

Gunnar Olerud