Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2014-01-16 09:27:59

On 01/16/2014 02:27 PM, Nat Goodspeed wrote:
> On Thu, Jan 16, 2014 at 7:51 AM, Giovanni Piero Deretta
> <gpderetta_at_[hidden]> wrote:
>
>> I think that Harmut point is that you can very well use threads for the
>> same thing. ...
>> The point of using fibers (i.e. M:N threading) is almost purely
>> performance.
>
> Again, for a large class of use cases, fibers and threads are not the same.
>
> Writing thread-safe code remains something of an art, a specialty
> within the already-rarefied realm of good C++ coding. With care, code
> review and testing, it is of course possible to produce good
> thread-safe code when you are writing it from scratch.
>
> But retrofitting existing single-threaded code to be thread-safe can
> be extremely costly. At this moment in history, we have a very large
> volume of existing code whose developers (perhaps unconsciously)
> relied on having exclusive access to certain in-process resources.
> Some of us do not have the option to discard it and rewrite from
> scratch.

Even in the context of a Boost.Fiber like library, you have to take 
extra care to secure your data structures from concurrent access. Even 
though it is not necessarily running any threads in parallel, a fiber 
can suspend while being in a critical section. BTW, from our experiences 
with HPX, such a behavior (suspending a user level thread while a lock 
is held) is very dangerous and often leads to deadlocks.
That being said, even when you decide to use fiber with your legacy 
code, the cost to make it safe is not really negligible.

>
> Yes, this is a subset of the possible use cases of the Fiber library.
> It is an important subset because threads provide no equivalent.
>
> Yes, I also want a Boost library that will concurrently process very
> large numbers of tasks, with each of a number of threads running very
> many fibers. I think the Fiber library gives us a foundation on which
> to build that support. But even with its present feature set, with
> Oliver responding to the community, it has great value. I feel
> frustrated when people dismiss the very real benefit of cooperative
> context switching as irrelevant to them.

Noone said it's irrelevant. The point was that performance should be the 
major criteria to accept the library.

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>