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.
If the fibers are not stolen by other worker-threads it should be not be an issue. Only tasks/actions which are stored in the worker-queue can be stolen and will be fiberized by the stealing worker-thread. regards, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger