Forward Progress in C++ - Olivier Giroux - CppNorth 2022
ฝัง
- เผยแพร่เมื่อ 26 ส.ค. 2024
- CppNorth Twitter: / cppnorth
CppNorth Website: cppnorth.ca/
---
Forward Progress in C++ - Olivier Giroux - CppNorth 2022
Slides:github.com/Cpp...
CppNorth 2022 video sponsors:
think-cell: www.think-cell...
Adobe: cppatadobe.spl...
If you are coming to a C++ conference, then you probably have heard of the memory model before now. But what have you heard about forward progress guarantees in C++? Without forward progress, most synchronization is meaningless, making the topic a pre-requisite.
Unlike the memory model, however, it is not really an option to leave the topic to experts. That’s because assumptions of progress are implicitly part of the contract for calling libraries that synchronize inside. So, unless you are writing purely serial code, you are making assumptions about forward progress in your C++ code.
This talk will provide a whirlwind tour of the subject - foundations, interactions and practice. I will provide references for further reading as much as possible.
---
Olivier Giroux
I am a veteran GPU architect of 20 years, an ISO C++ committee member of 10 years, and its chair of concurrency and parallelism for the past 4 years. I'm the only hardware engineer on the committee. I like to talk about formalizations of parallelism and memory models.
---
TH-cam Channel Managed By Digital Medium Ltd: events.digital...
---
#Programming #Cpp #CppNorth
This is one of those talks that I have watch multiple times to get a koan of wisdom out of it. Extremely useful, and a part of C++ that has really not been covered so well in other talks I've seen on youtube.
"Unsequenced execution policies are the only case where function calls are unsequenced with respect to each other, meaning they can be interleaved. In all other situations in C++, they are indeterminately-sequenced (cannot interleave). Because of that, users are not allowed to allocate or deallocate memory, acquire mutexes, use non-lockfree std::atomic specializations, or, in general, perform any vectorization-unsafe operations when using these policies (vectorization-unsafe functions are the ones that synchronize-with another function, e.g. std::mutex::unlock synchronizes-with the next std::mutex::lock)"
Newer talk with the same title which I found easier to understand: th-cam.com/video/g9Rgu6YEuqY/w-d-xo.html