----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> 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