Am Mittwoch, 5. November 2008 16:11:38 schrieb vicente.botet:
In my opinion the scoped constructions do not work well to configure the threadpool, as we have no multiple threads that can configure the same object.
noticed that in one implementation
I don't know if both can be configured at the same time.
At least we have two variables to configure: task submision : where a task will be enqueued (pool queue or worker thread queue) blocking behaviour: what the scheduler does when we block e.g. on get (blocks, schedule recursilvely, use fibers, ...)
Concerning the working thread in addition we could consider whether other working thread schedulers can steal tasks for this working thread queue.
I'm not sure if we need all these variations, but it would be better to separate the concerns and see how this work. We need to see how all variables interacts and which ones are compatible and/or desirables. For example if the task is submited on the internal queue and the scheculer blocks on blocking functions these task will never run.
Your first thread_pool uses the pool thread, don't have internal queue and don't steal from others working threads, and of course do not allow others to steeel because there is nothing to steal. Of course it blocks on blocking functions.
The fjTask and TBB allows to submit on the pool thread or on the internal queue (parent task concept), schedules recursively when blocking and allows others working thread to steal tasks from its internal queue.
My opinion: 1) work-stealing will be used when possible (can not disabled) 2) fork/join: recursivly executing arbitary task from the pool is wrong - only tasks-trees should be executed recursivly 3) forthe problem a sub-taks waits for an notication (condition variable) from its paren-task can be solved with fibers item 1) is implemented item 2) and 3) I#ve think about intreface and implementation regards, Oliver