On 09/06/2015 06:12 AM, Oliver Kowalke wrote:
2015-09-06 2:27 GMT+02:00 Vicente J. Botet Escriba
mailto:vicente.botet@wanadoo.fr>: Completely agreed. We need fibers migration when we associate a fiber to a job/work and we have work stealing.
I don't know why you ignore the problem of TLS and compiler optimization in the context of work-stealing - this is an issue.
It's certainly an issue in user code which relies on the address of a thread local variable to stay the same. The Fiber library, itself however should not be affected by this. That is it can safely store a reference to the currently running fiber or thread manager in a TLS variable. The trick is, of course to update the variable on each context switch. Let's analyze the situation a little further. Here is a link to the slightly changed code from http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread...: http://goo.gl/A9J7ae The compiler has of course any right to assume the address of test is constant in any case, as such, it has every right to "cache" it somewhere. However, as soon as you try to get the *value* of that thing, no such optimizations are possible anymore because bar() is aliasing it (in fact, since it is a global variable, it is aliased by anything and it can't be "cached"). As such, storing the result of "this_fiber::get_id" into a TLS variable is safe even in the presence of migrating fibers to other threads. You can even further relax the situation if you use something like the baz function, where the compiler has no notion of where the pointer is coming from. This of course completely ignores how user code might use thread local variables, which I still believe should be highly discouraged when using anything fiber-like. But it is still not in the scope of Boost.Fiber to make that decision, it should be possible to migrate fibers to other threads.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users