Working with Asynchrony Generically: A Tour of C++ Executors (part 2/2) - Eric Niebler - CppCon 21
Vložit
- čas přidán 28. 05. 2024
- This is Part 2 of a 2 part talk. Part 1 available here: • Working with Asynchron...
cppcon.org/
github.com/CppCon/CppCon2020
---
Asynchrony is increasingly important across the software industry, yet C++ lacks a standard async programming model or a comprehensive set of asynchronous algorithms. In this talk, Eric will describe the approach to asynchrony taken by standard Executors, currently targeting C++23. This talk with focus on how to use the new facilities, with glimpses under the covers to see how things work.
"Asynchrony" means many things. It means concurrency (e.g., thread pools) and parallelism (e.g., GPUs). It means parameterizing a computation on where it should execute. It means the ability to chain work, propagating values and errors to user-specified continuations. It means forking and joining async control flow without blocking. It requires guarantees that async work can make forward progress. It means a standard way to request that a computation stop early, and a way to propagate the "I have now stopped" notification back to the caller. And -- since this is C++ -- it means doing all that with bare-metal performance and seamless integration with C++20 coroutines.
The async programming model espoused by the recent standard Executors papers satisfies these constraints while also enabling a full suite of Generic asynchronous algorithms. C++23 will likely come with algorithms such as `then` for chaining work, `timeout` and `stop_when` for cancelling work after certain criteria are met, `when_all` for launching concurrent work and joining (without blocking), and `sync_wait` for blocking until work has finished.
The core abstraction of the Executors design, known as "Sender/Receiver", is to asynchronous algorithms what the STL's "Iterator" abstraction is to sequence algorithms: an enabling abstraction that makes reusable algorithms possible. With the containers and algorithms of the STL, the C++ Standard Library took a giant step forward in power and reusability. With C++23 Executors, the Standard Library takes the next step.
---
Eric Niebler
Eric is a long-time member of the ISO C++ Standardization Committee, and is probably best known for his work bringing ranges support to the C++20 Standard Library. He specializes in modern C++ library design, authoring several Boost libraries and the popular range-v3 library for computing with ranges and range pipelines. He currently works at NVIDIA where he is trying to build abstractions for asynchrony that are fit for standardization.
---
Videos Recorded & Edited by Digital Medium: online.digital-medium.co.uk
Register Now For CppCon 2022: cppcon.org/registration/ - Věda a technologie
it's mesmerizing to me why coroutines don't have a cancellation mechanism
Great talk.
I have a feeling this is gonna be one of these talks that newbies like me keep coming back to years later as one of the best talks on this (once this gets in the standard!).
template< class ExecutionPolicy, class ForwardIt, class UnaryFunction2 >
void for_each( ExecutionPolicy&& policy, ForwardIt first, ForwardIt last, UnaryFunction2 f );
How to use stop_token here? To stop the tasks and the loop!
This is an excellent question. We're still designing the async parallel algorithms (the one above is synchronous), and I haven't been thinking about how to communication stop tokens, allocators, and such into the algorithms. I'm adding that to the list of requirements. Thanks.
The funny thing about the Keyboard-intercepting API is that you can do the same thing (and more) on the Linux X-server... except on that platform, it doesn't even require administrator rights.
39:00 Not one, but two ways! You can use the raw input API as well! The craziest thing is that neither API requires any special permissions!
I actually have found it useful (sans the permissions part). Like one time I had a keyboard (mechanical :) ) that I thought had a bouncing key, but I wasn't sure if I was just crazy. I was able to write a logger that recorded key bounce events while I was typing normally and confirmed that I did in fact have a bouncing key. I also used the equivalent mouse hook API recently to implement some touchpad gestures.
One of the first C programs I ever wrote for windows was a hardcoded key remapper which used a lowlevel keyboard hook to get desktop-wide / global key events; it would swallow the original keypress event message and then send a different key. I remember being surprised that windows would just let me do that, and that it worked so well
set_done for cancelled... I'm literally speachless...
It's been renamed to set_stopped in the latest draft of the proposal.
@@EricNiebler But is it stopped or cancelled? Because those two don't mean the same thing you know. I'm laughing because after n-th revision finally all the "clever" people finally will name something that has been cancelled to set_cancel. LMAO.
Yeah, why not make it meaningful with set_cancelled instead of set_stopped
honestly, c++ committee should stop inventing, keep their egos aside and consult with new language authors. Golang Context is so easy and intuitive to use. C++ tends to do simple things in cryptic way.
My thoughts exactly... For years now I was amused at the ways C++ managed to make simple things very complicated. Luckily I've discovered Rust. It was like a breath of fresh air.
It's always amusing to see how each of us beggars praises his little bag :)
I find it annoying, counter intuitive and confusing what Java guys are doing, my Java guy work colleagues find C++ annoying, counter intuitive and confusing...
I land on mines in Java that confuse people how I even thought of doing that, my work colleagues land on C++ mines that I haven't found in the past 15+ years as it hasn't even crossed my mind to do something the way they intended it...
And then along come Go and Rust, holding the gods by the balls once again... And the history repeats...
Don't confuse your familiarity with quality and simplicity, and don't expect that others have the same familiarity burnt into their bones and thus find the same things simple...
Fortunately there is more than one language and in each of those languages you can solve the same task in more than one way so that your world view can stay in tact inside that nice little sandbox...
@@romeklomek5646 It's funny that while I was learning Rust I was confused as to what's the purpose of that language since idiomatic Rust looks the same as my (perhaps idiomatic?) C++ code...
A year later it turned out that I was looking at that language from the wrong direction - it's not there to make a good C++ programmers code better but to save that programmer from mental breakdown while trying to explain to others why it's a bad idea to use a pointer or mutex that escapes encapsulation just because they can... In Rust the compiler is the one that does the "I'm sending you and your half baked code somewhere where the sun doesn't shine" part so that you can stay the nice guy.
I'm always afraid when people praise Rust for structuring better and simpler code... As that's definitely not what the language does (it just prevents programmers from showing their dubious taste that they can express in other languages).
Side note... I once wrote a Prolog program as if Prolog is C++/Java/Delphi as I didn't feel like learning that language at that point in time. The code worked. The code was unreadable. The code was longer than it needed to be. It was not the language's fault - the problem was familiarity, taste and knowledge of the person between the keyboard and the chair.
It always makes me wonder how often this keyboard-chair problem applies to others proclaiming their familiarity and taste as the sole indicator of quality and/or simplicity.
@@DerDoMeN I've been with C++ for many years, far far longer than any other language, to the extent I believe I can call myself an expert. I find all of these coroutine related stuff impenetrable and convoluted. On the other hand, Go concurrency is so stupidly simple it literally takes a day to learn it from the ground up.
@@passerby4507 isn't go garbage collected? That's a whole part of the complexity gone right there, but also of the performance. The C++ execution model is being architected so you can do all this stuff with as few heap allocations as possible. So you get all the gory details garbage-collected languages hide from you.
The only thing they could do to make this simpler is transform some of these constructs into language-native ones with new keywords, but they can't introduce those willy-nilly without major breaks to backwards-compatibility.
It's worth following Herb Sutter's CPP2 though, as with the new syntax he's able to massively simplify multiple C++ features such as universal references forwarding.
__reserved__