Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13

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://lists.boost.org/mailman/listinfo.cgi/boost-users
>