Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk