Structured Concurrency: Writing Safer Concurrent Code with Coroutines... - Lewis Baker - CppCon 2019

Structured Concurrency: Writing Safer Concurrent Code with Coroutines and Algorithms
CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2019
-
Traditional approaches to concurrency and asynchronous programming, such as futures or threads, can be difficult to use safely, particularly in the presence of exceptions. These abstractions often implicitly introduce concurrency to your program in an unstructured way making it difficult to reason about your code.
The principle of “structured concurrency” aims to do for concurrent/async programming what constructs like if/while/for did for control-flow and what destructors and RAII did for object lifetimes - provide a structured way to think about concurrency in your programs by encapsulating common concurrency patterns into reusable algorithms.
This talk covers using the principles of “structured concurrency” in conjunction with coroutines to make it easier to write concurrent programs that are safer and more efficient than traditional approaches.
-
Lewis Baker
Software Engineer, Facebook
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@MuraliSprofile]

My Notes:
18:55 - 21:45 ProblemA: Bugs while concurrently executing two futures
29:46 - 34:30 SolutionA : Be Lazy, use tasks
35:27 when_all(), when_all_windowed(), timeout()

[@aaronyoung109]

Thought this was a great talk, and put concisely in to words many ideas and issues I've come across myself. I found it interesting that there were two questions in the end, one about cancellation, and a second about UI's... A previous project I worked on was built around a composable, "cancellable task" abstraction, that was used to express UI workflows. That is, instead of statically-wired callbacks (e.g., "on click" handler), user interactions are modeled as tasks that are explicitly started (e.g., "wait for click") and composed with tasks associated with non-UI things (devices, external services, etc) in a very consistent way, using algorithms very similar to what Mr. Baker discusses in the video (when_all, when_any, etc). Makes it much easier to statically reason about what side-effects are "in play" by reading the code, rather than relying on observational conclusions using debuggers or logs.

[@AnthonyDentinger]

Yeah, the way you explain it does make it look like it would be better to readon about the code. Of course, most UI frameworks tend to be event-based, so if you work with one you don't have much of a choice than to do event-based UI, but interesting still!

[@Roibarkan]

Great talk. I think slide 71 has a small typo: “tasks” should be “paths”

[@valera16011990]

We can implement same logic for eager futures WhenAll as for lazy tasks WhenAll. So in user code we don't really have a significant difference
But WhenAny not really good works with structured concurrency, of course we can cancel other tasks, but cancel task, not really fast
Honestly I don't think detach asynchronous operation always bad. For me exist many case when its ok

[@think2086]

Note: typos starting @19:32 and @21:33 : second `uid1` should be `uid2`