16

I am reading http://olk.github.io/libs/fiber/doc/html/ It seems to me that with Boost.Fiber C++ is coming closer to Erlang's ability to have thousands of "processes", also known as "green processes[threads]" http://en.wikipedia.org/wiki/Green_threads.

My question is, is Boost.Fiber ready for production, are there now c++ alternatives that have better documentation and examples? Someone mentioned lightweight threads, but I can't seem to find a reference to it. One final question is, why doesn't the C++ standard include Fibers?

The reason I am interested in this is because I have realtime updates where a value change can impact (spawn) hundreds/thousans of small but embarrassingly parallel computations. The C++ thread model doesn't work very well, imo. Please no GPU, since it currently takes too long to transfer the information to and from the GPU.

I realize that Erlang is far more than this so please don't educate me on Erlang vs C++ in the general case.

Ivan
  • 7,448
  • 14
  • 69
  • 134
  • Really this is a problem with scheduling and context switching: http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf – Ivan Nov 19 '14 at 18:08

1 Answers1

15

Boost.Fiber was reviewed by the Boost community in January 2014 and was found to need significant additional work. See the results of the community review at http://lists.boost.org/boost-announce/2014/01/0393.php.

C++ 17 also looks to gain a WinRT like M:N threading model based around resumable functions using the proposed await keyword. Microsoft have implemented support in their compiler, and apart from magic memory allocation tricks for futures it looks very promising. The relevant N paper is N4134 (http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4134.pdf), and as you will see that if accepted, this formulation of resumable functions would indeed provide Erlang type scalability even if the syntax is a bit obtuse (hey, it's C++, when is its syntax ever straightforward!).

Of course, if you need a portable solution now, either go the stackless coroutine route with ASIO (caution: it's brittle), or finely grain ASIO handlers with ASIO strands using a class instance as your execution state which is much the same thing, or else use Boost.Fiber anyway. If you only need Windows, I'd press ahead with Microsoft's proprietary extensions myself, they are highly unlike to abandon them unless they abandon WinRT :)

Edit: The author of Boost.Fiber tells me that as of January 2015 the recommended changes from the community review are complete, and apart from documentation improvements Fiber is considered ready for inclusion into official Boost. If this is indeed the case, then Fiber is probably the best solution before official C++ 17 language support for final resumable functions appears in compilers.

Niall Douglas
  • 9,212
  • 2
  • 44
  • 54
  • Thanks. That is actually helpful and interesting. One thing that I have noticed is that first C++14/17 has to implement the notion of parallelism first in order to implement these notions. So does std::await make sense without std::thread, or std::threadpool? – Ivan Jan 12 '15 at 16:20
  • @Ivan: You pretty much hit the nail on the head about the committee deciding on what parallelism model to use. I would say they are currently split on that, with Hartmut (via HPX) and Microsoft via WinRT taking a M:N threading model where M is kernel threads and N is coroutines. Also, just because the Concurrency study group have one opinion doesn't mean they will persuade the committee necessarily, though if let's say clang and MSVC both implement the experimental compiler support I'd say that would seal the discussion. – Niall Douglas Jan 12 '15 at 17:26
  • @Ivan: Regarding await (not std::await, await will be a keyword) requiring std::thread, the current plan is that there is a future and thread concept (remember concepts are in C++17), and if a type declares itself as implementing the concept then in theory the compiler will accept that. Therefore boost::thread should work with await just as well as std::thread, similar for boost::future vs std::future. – Niall Douglas Jan 12 '15 at 17:28
  • Niall thanks. I am getting a clear picture of where this is going. I didn't realize that await would be added to the core language. I really hope that whatever is decided, that being able to use tens of thousands of "processes" is no big deal the way it is in Erlang. I expect computers to have a million "cores" in ten years. – Ivan Jan 13 '15 at 17:34
  • 1
    @Ivan There is [a recent cppcon talk](https://youtu.be/e-NUmyBou8Q) about Fibers, which compares them to async and also has performance comparison with Erlang (as well as others) – user362515 Oct 08 '16 at 20:31
  • Additionally Boost.Fiber is now in the main Boost distro – Niall Douglas Oct 11 '16 at 13:45