Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-16 08:41:58

> > 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.
> 
> Yes, this is a subset of the possible use cases of the Fiber library.
> It is an important subset because threads provide no equivalent.

If the main target of Boost.Fiber is this use case (support
'multi-threading' in single threaded applications), then the way it's
implemented does not make sense to me. Why would you need a single atomic if
all you have is a single thread? And the source code has atomics all over
the place - thus I gather this use case was not what Oliver had in mind.

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

Why accept a library which is over-engineered for the advertised use case
(see above) and not (yet) fit for the broader one?

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu