Subject: Re: [boost] [threadpool] version 22 with default pool
From: Edouard A. (edouard_at_[hidden])
Date: 2009-03-08 13:38:05
> Am Sunday 08 March 2009 15:29:05 schrieb Edouard A.:
> > Unfortunately, I am unable to compile the tp library. TT
> Hmm - did you try version 23? I've no problems to compile default_pool(
Yes, this is version 23, I am using Visual Studio 2008.
> pool accepts multiple integer arguments (poolsize, high_watermark
> low_watermark,...) - with specific types for each argument the meaning
> each arg becomes clear (see scott meyers advise).
When I initialize a std::vector, I'm happy to be able to write std::vector<>
v(10) and not std::vector<> v(vector_size(10)). Sometimes parameter's
purpose is obvious. Your call.
> > When scheduling several tasks with submit, I find it odd that I don't
> > a pool.wait()
> pool::shutdown() or pool::shutdown_now() -> diff. explained in the docs
I'm afraid that the method name might be a bit misleading, I would expect a
shutdown() method to kill my pool and make it unusable for later use without
going calling startup() function.
> a task is finsihed if its result (shared_future) becomes ready ->
> shared_future< R >task< R >::result()
> void shared_future< R >::wait()
I guess your internal scheduler knows when all tasks are processed, why not
offering a condition variable... Otherwise it means I have to scan all the
tasks to know if they are all finished. But you pointed out shutdown() and I
think it will do the trick.
> > Some tests done with parallel "filling" on a concurrent_vector show
> > tbb does better but threadpool is not humiliated:
> this is clear because threadpool use a single-lock global qeue.
> I'm working on a lock-free global queue - I hope theadpool becomes
For long queues, most likely.
> the default pool should already be avaliable - I don't understand why
> initialize it with poolsize.
The shutdown() method's purpose was unclear to me before your explanation,
making it easier to create a pool and let the default destructor wait for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk