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

Подписаться 15 тыс.

Просмотров 4,1 тыс.

50% 1

ACCU Membership: tinyurl.com/ydnfkcyn
Sponsored By think-cell: www.think-cell.com/accu
accu.org
Designing for C++ Concurrency Using Message Passing - Anthony Williams - ACCU 2023
Slides: accu.org/conf-previous/accu2023/
One common way to design concurrent code with less potential for synchronization and other concurrency errors is to use message passing. In this talk, I will walk through the design of some example code, showing how to build such a system in practice
This talk will include a brief description of what message passing frameworks are, and how they can help avoid concurrency errors.
I will then work through some examples, showing how the tasks are divided between the elements, and how the system can therefore utilise concurrency, while insulating the application code from the details of synchronization.
---
Anthony Williams
Anthony Williams is the author of C++ Concurrency in Action, and a UK-based developer and consultant with many years of experience in C++. He has been an active member of the BSI C++ Standards Panel since 2001, and is author or coauthor of many of the C++ Standards Committee papers that led up to the inclusion of the thread library in the C++11 Standard. Anthony lives in the far west of Cornwall, England, and is currently working for Woven by Toyota developing automotive software.
---
www.accuconference.org/
RU-vid Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#accuconf #programming #cpp

Наука

Опубликовано:

4 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 11

@RishabhRD 10 месяцев назад

I was waiting for this talk for 2 weeks

@Dominik-K 10 месяцев назад

Loved the talk, really good reasoning

@supercompooper 10 месяцев назад

Good vid will share with my devs

@z140140 10 месяцев назад

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 10 месяцев назад

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

@fy282 8 месяцев назад

🎯 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

@SimonToth83 10 месяцев назад

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 10 месяцев назад

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 10 месяцев назад

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 10 месяцев назад

> 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 10 месяцев назад

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.