From: Atry (pop.atry_at_[hidden])
Date: 2007-05-06 19:52:03
Yuval Ronen åé:
> Here are a few classes which I think are very useful:
> 1. A thread_pool class. I think there's not much I can tell you that
> you don't know about it. It's something that has threads, and can
> accept tasks to be pushed into a queue, and executed in turn when a
> thread is available. It can also be suspended (stop handling tasks,
> but keep the threads alive) and resumed.
> 2. Two 'dispatcher' classes, one for plain threads, and one for
> thread_pools. They accept a single task, or several tasks, to be
> executed, either by dedicated threads (the thread_dispatcher class),
> or by a thread_pool (the thread_pool_dispatcher class). These classes
> provide a wait() method that block until all tasks are done.
> IMO, these classes fill a hole in the Boost.Thread library, and can be
> a basic for the future<> template (I have to admit I didn't follow the
> future<> discussion, so I hope there's nothing here to contradict any
> consensus reached in that discussion, if any).
> A few notes:
> 1. The semahpore class is there because it was needed for the
> thread_pool_dispather, but I think it will be a good general purpose
> addition to Boost.Thread. If I'm the only one thinking so, it can be
> moved as implementation detail of thread_pool_dispather.
> 2. The thread_task typedef should really be removed. Instead, a 'task'
> typedef should be added to boost::thread. So all occurances of
> 'thread_task' should be replaced with 'thread::task'.
> 3. I'm not sure about the name 'dispatcher', but couldn't find
> anything I'm happy with. Something that catches the essence of the
> classes. Any suggestions are welcome.
> 4. The thread_pool class can benefit from two additional features:
> 4.A. add_threads(size_t) and remove_threads(size_t). I think I can add
> those if found useful.
> 4.B. pre_loop and post_loop hooks to be executed by each of the worker
> threads in the thread_pool, immediately after creation, and before
> termination. I actually have a use case for those, but I don't want to
> distract the discussion from the main things.
> 5. The asserts in thread_pool::~thread_pool, thread_pool::suspend,
> thread_pool::resume, thread_dispatcher::~thread_dispatcher,
> thread_pool_dispatcher::~thread_pool_dispatcher are supposed to catch
> user errors. These asserts are questionable. I'm not sure whether
> those use cases are indeed errors, and if so, should assert be the
> right way to deal with them. I chose to be a hard-liner for now, with
> an option to soften.
> 6. The other asserts are there to catch errors in my code.
> 7. Some or maybe all of the asserts should be replaced by
> BOOST_ASSERT. I'm not sure of the Boost convention here.
> I hope it will be found useful!
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
We already have thread pool and dispatcher in Boost.Asio, although it is
a very simple one.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk