Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
https://github.com/boostorg/context/blob/6fa6d5c50d120e69b2d...
...and this causes problems, because it can't guarantee that all fields are initialized or switched successfully: https://lists.boost.org/boost-bugs/2014/10/38476.php
Microsoft continually adds and changes fields in the TIB with each new release of Windows. Attempting to implement fibers manually is a ticking time bomb that should never be used in production.
A disadvantage to the ‘no function coloring’ in fibers is that it makes lockless programming harder. A nested function call can switch from under you without your knowledge, making it hard to know where the preemption points are and whether to take locks when making updates to shared state. With function coloring you know exactly whether a function might switch or not.
I’ve programmed both fiber based systems and coroutines. I even created my own fiber libraries for Python (https://github.com/geertj/gruvi) and C++ (https://github.com/geertj/cgreenlet, mostly an experiment, and incorrectly named coroutines for C++ while it’s really fibers). In the Python version I experimented with some features to help you know whether a nested function might switch.
In the end, for me and for the problem domains I worked in, the explicit async/await co-routine style wins over fibers. It gives you most of the performance and memory benefits of user mode switching while keeping your code mostly lock free.
A disadvantage to the ‘no function coloring’ in fibers is that it makes lockless programming harder. A nested function call can switch from under you without your knowledge, making it hard to know where the preemption points are and whether to take locks when making updates to shared state. With function coloring you know exactly whether a function might switch or not.
I’ve programmed both fiber based systems and coroutines. I even created my own fiber libraries for Python (https://github.com/geertj/gruvi) and C++ (https://github.com/geertj/cgreenlet, mostly an experiment, and incorrectly named coroutines for C++ while it’s really fibers). In the Python version I experimented with some features to help you know whether a nested function might switch.
In the end, for me and for the problem domains I worked in, the explicit async/await co-routine style wins over fibers. It gives you most of the performance and memory benefits of user mode switching while keeping your code mostly lock free.
"Fibers", "green threads", "stack switching", "cooperative multitasking" are essentially all the same thing, they all rely on being able to switch to a different stack within the same OS thread. As such they can be implemented either in user space or by the OS.
Only downside of the technique is that it cannot be implemented in WASM, because WASM has separate data- and call-stacks and the call stack is not accessible from within the WASM virtual machine (while 'async-await' which relies on code transformation can be implemeneted in WASM just fine).
There is a 'stack-switching proposal' for WASM though, but I don't know how what's the state of that:
https://github.com/WebAssembly/stack-switching
C++ ABI has some per-thread globals: the number that is returned from std::uncaught_exceptions(), and the chain of currently caught exceptions. For example in llvm this is available with a cxa_get_globals call:
https://github.com/llvm/llvm-project/blob/b05f1d93469fbd6451...
These need to be saved/restored when switching fibers, otherwise fiber switches from catch clauses (and destructors!) are unsafe, throw without argument may rethrow incorrect exception, code that commits/rollbacks based on uncaught exceptions counter will not work correctly, etc.
One example I know where this save/restore is implemented is the userver framework, but it seems to be unexpectedly rare in fiber implementations last time I looked.
Have you seen https://github.com/google/ghost-userspace
Thank you for this in-depth article.
I am a less than a C++ beginner but I asked Stack Overflow how to run C++ coroutines in a thread pool. It seems coroutines in C++20 are unfinalised but don't quote me on that but I did get some sourcecode for older versions of the C++20 standard.
I used Marce's Col's excellent blog post about how to create coroutines in assembly by adjusting the RSP pointer.
https://blog.dziban.net/posts/coroutines/
I extended Marce's code to run the coroutines in kernel threads:
https://github.com/samsquire/assembly (see threadedcoroutines.S)
I have been thinking of coroutines in terms of query compilation for database engines and the volcano query model and this article:
https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Tying together two pieces of code that call eachother in push or pull driven style is really powerful. Or if you're running multiple independent tasks that need their own state. This as I understand it is the original intent of object orientation that Alan Kay wanted and is represented by Erlang and partly Go.
Specifically, I am thinking of compiler created coroutines where code can be interleaved at compile time rather than at runtime.
Related posts
- Concurrent cron jobs?
- Resource efficient Thread Pools (with Zig)
- Question: Does Zig has work-stealing/sharing algorithm in the M:N concurrency model ?
- Need direction on how to add asynchronous / scheduled tasks on my flask app running on aws beanstalk
- Why Does Windows Use Backslash as Path Separator?