如何使用boost :: thread创建一个threadpool

Question

boost::thread is not-a-thread , a new thread is created when the ftor passed to it is called and thread exits when ftor returns.

We use threadpool to minimize thread creation and destruction cost. but each thread in threadpool is also destroyed when the supplied ftor returns.

So whats the basic concept behind building a threadpool ? is there any permanent thread where I can assign ftors to that thread ?

Answer 1

A thread pool is just a bunch of threads that already running, and that are all running the same function. This functions basically just waits on a queue, and when there is a "function" in the queue it extracts and executes it.

Pseudo-code:

void thread_pool_function()
{
    while (true)
    {
        wait_for_signal_that_queue_is_not_empty();

        function_to_call = queue.remove_top();

        unklock_queue_semaphore();

        function_to_call();
    }
}

create_thread(thread_pool_function);
create_thread(thread_pool_function);
create_thread(thread_pool_function);
create_thread(thread_pool_function);

In the "code" above there are now four threads, all initially waiting for something to be put in a "queue". When there is something in the queue, it extracts it, and calls it as a function.

This is probably the simplest way to implement a thread pool.

Answer 2

In addtion to what @Joachim posted:

One way to flow-control such a system (and one I use a lot), is to use a 'pool queue', (blocking producer-consumer queue), of tasks, created and filled at startup with a fixed number of task objects. Any thread that wants to issue a task has to get one from the pool first and tasks are returned to the pool after completion handling. This limits the number of tasks in the system and, if the pool empties, requesting threads just have to wait, blocked on the empty pool, until some 'used' tasks come back in.

This works well, provides flow-control, prevents memory-runaway and eliminates continual task create/destroy. It's also easy to periodically display/write the pool queue depth on a timer, so you can see how 'busy' your app is, (and detect any leaks:).

Edit: Also, it removes the need for any bounded queues in the system. Unbounded queues are simpler and tend to need fewer system calls.