Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-11-01 18:03:07

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. Whenever you would switch fibers to a new task,
just call the task recursively on the current stack instead. The
problem here is that you may run out of stack space if the recursion
is too deep: by creating a Fiber for the new task you can control the
stack space.

The problem with doing this (whether you use Fibers or just recurse on
the same stack) is that the nested task inherits context from its
parent: locked mutexes, thread-local data, etc. If the tasks are not
prepared for this the results may not be as expected (e.g. thread
waits on a task, resumes after waiting and finds all its thread-local
variables have been munged).

Anthony
-- 
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