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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk