Re: [boost] [threadpool] new version v12

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

k-oli_at_[hidden] writes:

> Am Sonntag, 2. November 2008 00:03:44 schrieb Anthony Williams:
>> > 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.
>
> Interessting - I'd like to see how the code works. Is it possible to access 
> your prototype?

No, sorry.

In future::get(), on a fiber-based thread pool you find a new
task/fiber and switch to that if the get() would block.

On a simple stack-based thread pool, you just look in the task queue
for a new task and run it.

>> 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.
>
> That's the way boost.threadpool uses boost.fiber (but fibers are not exchanged 
> between worker-threads -> work-stealing is done only on un-fibered tasks 
> waiting in the local queue of a worker-thread).
>
>> Doing either of these requires that the task is prepared for it.
>
> in which sense (sorry I'm not aware of)

Fibers are still tied to a particular thread, so thread-local
variables and boost::this_thread::get_id() still return the same value
for a nested task. This means that a task that calls future::get()
might find that its thread-local variables have been overwritten by a
nested task when it resumes. It also means that any data structures
keyed by the thread::id may have been altered. Finally, the nested
task inherits all the locks of the parent, so it may deadlock if it
tries to lock the same mutexes (rather than just block if it is
running on a separate thread).

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