Show HN: Coros – A Modern C++ Library for Task Parallelism (github.com)

I've just skimmed through the paper, and it raises interesting and valid point about scalability in parallel computing. I'll definitely look into it more thoroughly, as well as the talk you mentioned.

I'm glad you find the usage examples well-designed and appreciate your positive remarks about the library's architecture. Thank you again for your insights.

The paper is much more on the side of application and system performance. But you couldn't even write such a system without a library like this providing you the tools to do so. This is much more in the domain of "basic tool for ecosystem" than "library for specific tasks". It's on the user of the tool to address the paper's question, not the builder of the tools.

The idea is that only the owning thread can push tasks into the deque. If the owning thread detects that the deque is full, it creates a new one and copies the original values. Once the copy is ready, the owning thread "publishes" it by storing it in the buffer variable. Pointers to the deque are atomic, as well as the indices. Other threads can manipulate only the indices, and even if a stealing thread has an old pointer, it still points to valid data.

I hope I understood your question correctly and that this answer is helpful. You can find more details in the paper mentioned above.

[1] https://inria.hal.science/hal-00802885/document

- Heap allocated call frame. Instead of being pushed onto the stack, co-routines tend to have their call frame (local variables, arguments, etc.) placed into heap memory (or at least may be place-able into heap memory). This often enables the other features.

- Control can leave co-routines in more ways than standard function calls. Generally this means returning (often called "yield") to the caller without completing the whole function. It can then be later resumed, returning to where the function originally left off. Generators are a common pattern enabled by co-routines that rely on only this part (and so many systems can optimize out the heap usage, for example).

- A co-routine is usually an object with an interface that allows you to move it around and resume it in different places than it was originally called. This can include on different threads, or depending on the sophistication of the system, different processes or machines.

Those are the three big points in my mind. I'd recommend trying lua coroutines, personally (I like minmalist engines like defold to use it in) to really get a feel for how these are on the edge between "language feature" and "library feature".

In a nutshell, C++ coroutines are almost like regular functions, except that they can be "paused" (suspended), and their state is stored on the heap so they can be resumed later. When you resume a coroutine, its state is loaded back, and execution continues from where it left off.

The complicated part comes from the interfaces through which you use coroutines in C++. Each coroutine needs to be associated with a promise object, which defines how the coroutine behaves (for example, what happens when you co_return a value). Then, there are awaiters, which define what happens when you co_await them. For example, C++ provides a built-in awaiter called suspend_always{}, which you can co_await to pause the coroutine.

If you take your time and go thoroughly through the blog and Cppreference, you'll definitely get the hang of it.

Hope this helps.

[1] https://lewissbaker.github.io/ [2] https://en.cppreference.com/w/cpp/language/coroutines

They are a function that can remember where they are in their own execution so when they are called later they continue execution where they left of.

There are many many ways of implementing that functionality, C++ standard coroutines are only one such implementation.

What you do with them is whatever you want, it's pretty common to handle IO using them but generators are also a pretty common example. But that is generally high level.

C++ coroutines are basic building blocks and are very low level, there is no executor ( rust tokio / python asyncio ) so don't be worried if it seems hard to use, it is hard to use.

Look at std::generator for how coroutines are used to implement a generator, cppcoro is also a pretty popular library that builds abstractions on top of coroutines and also has some executors if I remember correctly.

you can even try to run those virtual threads on real threads. much fun to be had.

[1] https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous...

> they are functions that can suspend themselves, meaning they stop themselves without returning, even in the middle of their body and then can later can be resumed, continuing execution at the point they suspended from earlier.

If you want to use coroutines in C++ specifically you can have a look at this tutorial, if you want: https://theshoemaker.de/posts/yet-another-cpp-coroutine-tuto... I don't know of anyone that read it, but I spent a lot of time on it.

It essentially tries to explain how to build a coroutine support library yourself, but if you don't care about that, skip it and just use libcoro or cppcoro. They have examples too. My little async io library has some examples as well if you want to get an idea.

Notice that this does not necessarily involve parallelism, although it can. For example, Lua has non parallel (cooperative) co-routines. Go had parallel coroutins, called goroutines, but theoretically only if they they use channels to exchange values. Otherwise, if they’re not exchanging information they would not becoroutins in the sense that they work together in solving something.

This video is the best intro I've found. It actually explains what is happening in memory, which is the only way to really understand anything in C++.

https://youtu.be/aibjUHx7vew

Also this is decent:

https://www.scs.stanford.edu/~dm/blog/c++-coroutines.html

But don't try and write a coroutine library yourself. Use something like libcoro.

I've included a link to Lewis Baker's blog (the author of CppCoro) in my repository as an excellent explanation of coroutines. From my understanding, after reviewing his library, it is no longer in active development and hasn’t been updated for a couple of years. CppCoro was an experimental library intended to explore coroutines while they were still an experimental feature. For example, CppCoro uses a custom type for storing values, similar to std::optional from the standard library (if I'm not mistaken).

For my implementation, I've opted to leverage std::expected from C++23 for storing values. I've also implemented monadic-like chaining. CppCoro, however, seems to focus more on asynchronous operations, whereas my library focuses more on task-based parallelism.

I don't have experience with Boost.Cobalt, so I can't provide insights there, but I will definitely look into it now that you've mentioned it.

Hope this helps.

Most of the magic methods expected by C++ compilers in awaitable types, are also present in the structured typing used by C# for awaitables.

The preview implementation for VC++ and clang were done by a Microsoft employee, Gor Nishanov, his talks are always quite interesting.

I understand that working with tasks and retrieving values can feel a bit clunky. The main reason I've structured it this way is that individual tasks are RAII objects, and their coroutine state is destroyed once they go out of scope. However, I could modify the awaitable returned from wait_tasks to store tasks, and then return values directly to the user. This could definitely be a more ergonomic overload for the function. I'll look into it!

I don't have experience with WinRT, but it does seem quite similar at first glance. One of the key reasons I focused on modern C++ was to ensure cross-platform compatibility. However, I completely understand that if you're working on Windows and are already familiar with WinRT, sticking with it makes perfect sense. I'll take a closer look at WinRT to see if there are any significant differences.

During development, I initially tried implementing coroutines in a way that executing them without spawning a new thread would be possible. However, it introduced complications, so I eventually scrapped that approach.

Now, with eye on potential improvements, I can revisit this idea from the perspective of I/O operations.

I've skimmed through Taskflow, and from what I understand, its main focus is on graph parallelism, allowing users to express computations as a graph.

I haven't done extensive benchmarking against 3rd-party libraries yet, which others have also mentioned. I'll definitely do more performance testing in the future to better assess and optimize performance.

I hadn’t come across folly::Coro until now. It does seem quite similar at first glance, and some of the utility functions they have are ones I’m also planning to implement, as others have also pointed out are currently missing.

One difference is that they use a custom Try<T> type for handling exceptions and values, I’ve opted for std::expected introduced in C++23. I’ve also added "monadic-like" chaining of tasks.

Overall, it’s a very similar library, and I’ll definitely look into it for inspiration and potential improvements.