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

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-05 14:23:40

2015-09-05 20:22 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:

> 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 would not expect this and I don't see why your test code proves that
fibers (which do not migrate) should not use TLS
In your example you could also remove thread_local and you would get the
first result

>
>
>> 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.

you misunderstood my previous post - boost.fiber is completely unaware of
NUMA - as I wrote NUMA utilization is part of boost.job (uses boost.fiber)

> Especially since not all algorithms are memory bound. For compute bound
> problems, fiber migration across NUMA domain boundaries is not a big deal.

yes maybe

> For memory bound problems, stealing inside of a NUMA domain can be
> benefitial.

agreed

> All in all, it is not something the fiber library should decide but rather
> its user through the use of appropriate schedulers/executors.
>

as I already mention before