Designing for C++ Concurrency Using Message Passing - Anthony Williams - ACCU 2023

[@fy282]

🎯 Key Takeaways for quick navigation: 00:22 🚀 Discussing designing for concurrency using message passing in C++. 03:10 🚫 Avoid shared mutable state when using message passing to prevent data races. 05:04 🛠️ Designing for message passing requires a unique approach. 10:28 📬 Process one message at a time per microservice for isolation. 17:00 🎯 Microservices should have a single task and use simple messages. 22:45 🔄 Model microservices as state machines to simplify message handling. 26:17 🤖 Isolate blocking I/O to dedicated microservices. 32:46 🥢 Manage shared resources like chopsticks efficiently. 47:21 🤖 Use state machines for complex robot control sequences. 51:48 🚀 Test by running everything on one thread. 53:27 🤝 Microservices focus on messages without synchronization. 55:40 📧 Use value type messages. 56:26 ⏳ Replace blocking calls with microservices. Made with HARPA AI

[@RishabhRD]

I was waiting for this talk for 2 weeks

[@Dominik-K]

Loved the talk, really good reasoning

[@supercompooper]

Good vid will share with my devs

[@z140140]

I wonder did he ever read "Communicating sequential processes" by Hoar? I understand, being 40 years old, it's a rather new book, but Occam, Erlang and Go were built on this theoretical foundation long before he got the intuition that message passing can be used for reliable multithreading

[@AnthonyWilliamsAAJW]

Yes, it's a great book. If you truly grokked it, there's probably not a lot new in my talk.

[@SimonToth83]

The repeated talk about isolating blocking operations was quite bizarre. What exactly are you gaining? 1. The logical context cannot continue, because if I'm waiting for OnXDone, where X is a blocking operation, it doesn't matter how X gets done. 2. The execution context cannot continue, because it is blocked by a blocking operation. It doesn't matter if that blocking operation is part of a large block of code, or a small block of code. In the summary you said that this allows you to give each actor that can block an exclusive thread. Well first, you might not have enough threads to do that, even more importantly, combined with isolating the operation are enforcing a strictly serial operation. That's suitable for only very narrow contexts. I definitely don't want backends like a distributed database to be throttled to a single query at a time.

[@AnthonyWilliamsAAJW]

The reason for avoiding blocking operations is precisely to address these issues! If you *must* block, then having the blocking operation on a dedicated context means that only that execution context is blocked. Every other part of the system can continue. Code that is waiting for the response message will just not receive the message until the blocking operation has finished, and sent the response message, but it won't occupy any execution resources in the mean time. Any operation that blocks already enforces a strictly serial execution around that operation: the executing thread cannot do anything until that operation has completed. I would hope that a database would allow multiple async queries. If it doesn't, then write a wrapper that accepts messages, passes them to the database code so that the db code can send a response message when it is done, *and then returns control to the message driver*. Isolate the blocking code off to the side in the db wrapper, so the message processing is entirely non-blocking.

[@thisisolorin394]

when blocking synchronously on a system with a single thread, it makes no difference. For all other cases (async blocking and/or multithreaded scheduler/runtime) it does make a difference. You generally do not want to block the actor's loop so it can keep processing other messages, so it's best to delegate the blocking work else where and send the result back to the actor when it's finished

[@russianbotfarm3036]

> hiding blocking Yeah if feels like an infinite regress. _something_ has to actually do eg an OS-level i/o wait. I guess that gets an OS thread, and the ‘actor’ that uses it is a piece of state machine that gets an OnIoDone() event. > not enough threads There’s no practical limit to threads, whether they’re OS threads or green threads. > distributed database Give it a pool of threads of the size of the number of transactions it can handle at once. Dunno.

[@thisisolorin394]

I'm a big fan of Concurrency in Action, but this talk was a bit underwhelming. It's very high level and doesn't use any actual C++ framework. It's more of a showcase of message passing than anything else. There is absolutely nothing C++ specific in this talk.