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