Menu
I just started having a look at go and how the concurency in go works. I just wondered if you could implement something equal in C++ and found boost.fiber. What's the difference between goroutines and boost fibers? Could you implement something goroutine like with those fibers in C++?
750
Goroutines are useful when you want to do multiple things simultaneously. For example, if you have ten things you want to do at the same time, you can do each one on a separate goroutine, and wait for all of them to finish.
In Golang, Goroutines are used to achieve concurrency. They are lightweight threads managed by the Go runtime. Goroutines make it possible to create concurrent programs that can execute tasks faster than a regular sequential program would.
A goroutine is a lightweight thread managed by the Go runtime. go f(x, y, z) starts a new goroutine running f(x, y, z) The evaluation of f , x , y , and z happens in the current goroutine and the execution of f happens in the new goroutine.
Goroutines and fibers are the same thing: M:N threading. It is true that many of the fiber issues presented here are C++-specific.
So from what I could gather from the source code of the boost.fiber library, it seems that it is indeed MUCH more versatile and powerful than goroutines. The mantra of goroutines is to not share data between the coroutines, but rather pass data into them as necessary. This is apparently possible within fibers as well with channels (boost::fibers::unbounded_channel<T> and boost::fibers::bounded_channel<T>), although one thing I'd keep in mind is data is safely shared between all fibers in a single thread. This is managed (by the use of mutexes, I guess) to ensure only one fiber runs at a time, so you may not need channels for a particular use case.
Fiber also seems to give you control over the synchronization of fibers within threads it seems. Apparently I/O that blocks will block an entire thread that the fiber running the operation is in, which makes sense. The cooler thing is that you could use Fiber to simulate blocking (e.g. for strict order of routine scheduling) if needed. There is a pretty good example of custom scheduling of fibers based on priority queuing here https://github.com/olk/boost-fiber/blob/master/examples/priority.cpp as well. However, I'd be willing to bet that scheduling defaults to interleaving them
So just to summarize, it seems the main points to take away are that yes, Fibers already has goroutine-like stuff already implemented. You have channels, you can multithread (and I'm sure this can be extended to multicore fun as well), and you can run async operations in the same thread (again, I'm assuming they default to interleaved scheduling in the same thread). Fibers seems to have much more, context-switching, fiber-safe shared memory, while go tends to keep things restricted to data passing using channels.
Honestly you'd have to surf the codebase a bit like I did to see what else Fibers has, but yeah I'd say these are some main diffs.
143
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
