Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-05 14:22:14
On 09/05/2015 04:50 PM, Oliver Kowalke wrote:
> 2015-09-05 16:36 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]
> <mailto:thom.heller_at_[hidden]>>:
>
> Oliver, do you mind providing the rationale for why fiber migration
> has been dropped or point me to the section in the docs discussing this?
>
> of course, the documentation has a short description in the rational
> section (http://olk.github.io/libs/fiber/doc/html/fiber/rationale.html).
> I refer to Giovanni's more detailed explanation
> (http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread.html).
>
> because of compiler optimization the address of TLS might be
> pre-calculated, the access to TLS might be moved out of a loop, etc.
> even if boost.fiber would not use TLS (keyword thread_local), the usage
> of TLS in the user-code (executed by a fiber) is not permitted -
> this is an unacceptable restriction for users.
I think this is not a good argument against thread migration. While this
whole TLS issue is certainly something that can lead to very subtile and
hard find bugs, it's something that user level threads currently just
can't deal with properly. As much as they look like std::thread, this is
one of their limitations and usage of TLS should be highly discouraged.
Consider code like this:
void f()
{
static thread_local int i = 0;
std::cout << i++ << '\n';
}
boost::fiber f1(f);
boost::fiber f2(f);
This will print:
0
1
instead of what might be expected:
0
0
>
> I suggest a pattern like boost.job proposes - on a logical processors a
> worker-thread is pinned, running a pool of fibers (boost. job uses
> some aspects of NUMA architectures). The jobs can be synchronized by
> classes from boost.fiber.
I think NUMA awareness is something that is out of scope of Boost.Fiber
and should therefor not be used as an argument against thread migration.
Especially since not all algorithms are memory bound. For compute bound
problems, fiber migration across NUMA domain boundaries is not a big
deal. For memory bound problems, stealing inside of a NUMA domain can be
benefitial. All in all, it is not something the fiber library should
decide but rather its user through the use of appropriate
schedulers/executors.
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/boost-users
>