Subject: Re: [boost] [threadpool] new version v12
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-11-01 19:03:44
> Am Samstag, 1. November 2008 23:03:07 schrieb Anthony Williams:
>> k-oli_at_[hidden] writes:
>> > Am Samstag, 1. November 2008 19:35:23 schrieb Vicente Botet Escriba:
>> >> IMO, the implementation of the fork/join semantics do not need fibers.
>> >> The wait/get functions can call to the thread_pool scheduler without
>> >> context-switch. Which are the advantages of using fibers over calling
>> >> recursively to the scheduler?
>> > Please take alook into the example folder of threadpool. You will find
>> > two exmaples for recursivly calculate fibonacci. Configure the pool with
>> > tp::fibers_disabled and try to calulate fibonacci(3) with two
>> > worker-threads. Your application will block forever.
>> > Use the option tp::fiber_enabled and you can calculate any fibonacci
>> > number without blocking
>> I haven't looked at Oliver's use of Fibers, but you don't need to use
>> fibers to do this.
> The idea behind using fiber inside a threadpool is, that each worker-thread
> executes multiple fibers - fiber would yield its execution if future::get()
> would block (because future is not ready)
Exactly. That's what my prototype does too. My point is that you can
do this without fibers too, but you might run out of stack.
One thing you can do with fibers that you can't easily do with a
single stack is switch back to the parent task when the nested task
blocks. Doing so allows you to run *other* tasks from the pool if a
thread blocks and the task it is waiting for is already running
elsewhere. You can also migrate tasks between threads.
Doing either of these requires that the task is prepared for it.
-- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk