Keynote: Employing Senders & Receivers to Tame Concurrency in C++ Embedded Systems - Michael Caisse
ฝัง
- เผยแพร่เมื่อ 25 ส.ค. 2024
- www.cppnow.org
---
Keynote: Employing Senders and Receivers to Tame Concurrency in C++ Embedded Systems - Michael Caisse - C++Now 2024
---
Concurrency and asynchronicity are notoriously hard in baremetal systems which often provide few abstractions. One core, a few interrupt driven events, and communication that may produce errors or require cancellation and now we have a concurrency beast. Typical approaches range from ignoring the problem to inefficient and hard to maintain implementations. Senders and Receivers offers much in the solution space but is it the silver bullet we have wanted?
This talk shows how to use the Senders and Receivers pattern to solve increasingly more complex problems. We will use Intel's open source baremetal senders and receivers library as well as other open source packages to build elegant, declarative solutions to historically complex problems. Our target will be an ARM based development board controlling several devices.
While this talk is focused on concurrency in the embedded baremetal domain, the problems addressed and solutions showcased are applicable to many areas. Please join me as we explore how Senders and Receivers can be employed to tame the concurrency beast in event driven systems.
---
Slides: github.com/boo...
Sponsored by Undo: Debug your hardest C++ bugs with time travel debugging → Learn more at bit.ly/cppnow24
---
Michael Caisse
Michael started using C++ with embedded systems in 1990. He continues to be passionate about combing his degree in Electrical Engineering with elegant software solutions and is always excited to share his discoveries with others. Michael is a Principal Engineer at Intel where he works with a talented team putting magic into silicon.
When he isn't fighting with compilers or robots, he enjoys fencing with a sabre.
---
C++Now 2025 - 28th April - 2nd May
C++Now is an annual onsite international C++ programming and coding conference held in Aspen, Colarado. For all C++ developers, C++ software engineers and those involved with the C++ language, CppNow provides an indepth and technical content provided by the best and brightest C++ experts of the C++ world.
Annual CppNow Conference - www.cppnow.org
/ cppnow
/ cppnow
/ cppnow
/ cppnow
mastodon.socia...
Video Sponsors: millennium and think-cell
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
TH-cam Channel Managed & Optimized By Digital Medium Ltd: events.digital...
---
#boost #cpp #concurrency #embeddedsystems #programming
How is it that every time I tell my colleagues (working as an embedded C++ dev) "Hey guys, we have this repeatedly occurring design problem in our applications. You know what? I will write this super cool, heavily templated library that will get the job done in a unified way with a nice declarative syntax" there is this talk later *the same year* given by someone from Intel's embedded team where the prelegent says "You know what? We had this repe... So we've written the library. Here it is. Pick it" :| That was the case with cib, message library and now with groov. I absolutely love seeing such an approach in my beloved domain that is still swimming in the sea of 90's C-style souls!
I remember watching a seminal talk by Michael Caisse about Boost.ASIO when I was getting started with C++ and programming in general. This talk has the same charm. Thank you.
Thank you for the kinds words! I'm very excited about this design pattern. Look for a new conference talk on using senders before the year is out.
I can confirm - the same story, the same feeling :D
Excellent presentation 👍🏽
Note that personally I would have said that "sender factories" are the event generators, not only schedulers (which are also sender factories)
Great talk! Thanks Michael!
Thank you! I hope you found some useful concepts in the talk.
Great talk.
Thanks for this excellent presentation. I don't know if enough people in embedded systems appreciate this paradigm's value, independent of language or implementation, so any visualization of its application in the field is a service to the community.
Any firmware developer will be exposed to the design/architecture forces between schedule efficiency, modularity of components to be scheduled (down to the lowest level drivers), and reasoning of concurrent behavior. Every project I worked on was affected by exactly the issues Michael mentioned in the presentation, even if we considered them early on. If an RTOS is off the table (for whatever reason), it looks like this approach solves a huge part of the design space for systems that manage a lot of async behavior without dropping a lot of control.
I hope the quality of code generation and compile times will scale with the problems thrown at it. Another question is how well one can reason about the global schedule timing across all execution contexts, given that with "senders", they are composed of locally specified use cases.
Oh and the original video linked at 37:00 crashes TH-cam. Are all talks on async graphs just trolling?
Wait I had totally expected senders and receivers to be, exactly what senders and receivers are in every other language (channels). Why has C++ decided to take a concept and name it the exact same as some other, well established in other languages feature? That sounds like crazy land to me.
Also, why are senders and receivers looking like futures and promises in combination with coroutines in this talk - and more importantly - why are we needing *another* one of those systems?
These senders and receivers also look _identical_ to kotlins coroutines (or Rust's coroutines/async). Why has C++ decided to muddy the waters this bad when we have multiple large userbase languages with these features but they aren't called senders and receivers. From what I can tell, *many* languages has senders and receivers yet *none* of them look like coroutines like this. Am I wrong about this?
How is someone supposed to debug code written in terms of SnR? the standard version of the logging example is way more readable and comprehendible that the SnR version.
I can't believe I watched for 40 minutes to not get an introduction to senders.
Nice talk, but flaky. It doesn’t really reveal some insight into senders. Butter to watch after something else.
So annoying