k-oli@gmx.de writes:
Am Freitag, 12. September 2008 08:17:55 schrieb vicente.botet:
Well, we can see that the number worker threads depends on the fib_par parameter. As soon as the fib_par function waits on its sub_tasks t1 and t2, the worker thread cannot handle other tasks, so we need a thread available for fib_par(9) and fib_par(8). When this worker thread call fib_par(9) after launching fib_par(8) and fib_par(7) will be blocked to manage other task, ... Evidently this do not scale very well, so we can not use the threadpool library to address this kind of problems, in which the tasks is split on sub-task launched to be run in parallel, and the the parennt task waits on its child sub-task to do somthing.
The problem is caused by this code: return t1.get_future().get() + t2.get_future().get(); Because it blocks until t1 and t2 are ready -> dead lock possible.
Not if the thread pool can detect this scenario and handle it. For example, my prototype can handle void recursive_task(jss::thread_pool* pool,int level,int count) { { std::lock_guard<std::mutex> lk(iom); std::cout<<"level "<<level<<", count"<<count<<std::endl; } if(level) { jss::unique_future<void> f1(pool->submit_task_returning<void>(boost::bind(boost::type<void>(),&recursive_task,pool,level-1,1))); jss::unique_future<void> f2(pool->submit_task_returning<void>(boost::bind(boost::type<void>(),&recursive_task,pool,level-1,2))); jss::unique_future<void> f3(pool->submit_task_returning<void>(boost::bind(boost::type<void>(),&recursive_task,pool,level-1,3))); f1.get(); f2.get(); f3.get(); } } just fine, even with only one worker thread. Of course, if you nest too deeply it runs out of stack space :-( Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL