Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-03 03:33:49

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 03, 2008 9:05 AM
Subject: Re: [boost] [threadpool] new version v12

>>> 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.
>>
>> 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).

You are right Anthony, task behavior shouldn't depend on thread specifics, 
either thread id, locks or thread-locals data because other sub-tasks can 
migrate to this thread while waiting for the sub-task completion. The same 
occurs for programs that run well sequentially and crash when 
multi-threading takes place. This do not have as consequence that we can not 
use threads neither global variables but that we need to implement 
thread-safe functions and some times use for that some  kind of thread 
synchronization, other use threads specific variables instead of global 
variables.

For task the same applies; there are some entities(functions, classes, ..) 
that are task-safe and others that need some task specific synchronization 
tools to ensure task safety.

I think the fork/join framework work well for task-safe entities while will 
have unexpected behavior otherwise.
* The first question is whether we can use such a framework knowing that we 
need to take care of the task safety or discard it because it is dangerous 
when the entities are not task-safe.
* The second question if we use this kind of framework is how can we make 
task-unsafe entities task-safe using some kind of synchronization or 
specific context at the task level.

I'm really interested in exploring this task space.

Vicente