Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net