Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-06 08:11:15
On 09/06/2015 06:12 AM, Oliver Kowalke wrote:
> 2015-09-06 2:27 GMT+02:00 Vicente J. Botet Escriba
> <vicente.botet_at_[hidden] <mailto:vicente.botet_at_[hidden]>>:
>
> 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.html:
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_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/boost-users
>