CppCon 2018: Geoffrey Romer “What do you mean 'thread-safe'?”

—
—
How can we communicate with other developers about the safety of our C++ code against the hazards of concurrency? Terms like "thread-safe" don't always have a clear meaning, and more precise terms like "data race" and "race condition" often operate at the wrong level of abstraction. In order to communicate effectively about these issues, we need straightforward ways to talk about the safety requirements that APIs impose, and what goes wrong if you violate them.

In this talk, I will present the simple yet precise vocabulary we use for talking about these issues at Google: an "API race" happens when two operations access the same object concurrently, in violation of its contract. For most C++ types, that contract can be classified as "thread-safe" or "thread-compatible" depending on what combinations of operations can cause an API race (the remainder are called "thread-unsafe"), and that two-word classification usually tells you everything you need to know to avoid API races on the object. This is significant because if you can avoid API races, you can avoid not only all data races but also many race conditions.
—
Geoffrey Romer, Google
Software Engineer

I'm a Staff Software Engineer on the C++ Library Team at Google, and the lead author of Google's C++ concurrent programming guide. My work focuses on improving the C++ programming experience at Google and beyond, which has led me to focus on problem areas such as concurrent programming, error handling, hashing, and memory management. I'm a co-owner of Google's C++ style guide, and have been active on the C++ Standards committee since 2014, including a stint as editor of the Library Fundamentals TS. Currently, I'm leading Google's efforts to adopt coroutines in C++, and working on API designs for mitigating speculation attacks such as Spectre Variant 1.
—

*-----*
*-----*

[tourdesource]

Definitely a talk that has to be watched more than once...

[sanjuuyonsai]

18:11 std::function is like a pointer. Just because the std::function object is const does not mean the wrapped call is a const call. It is like a const pointer to a non-const object.
I'm surprised this example is worth mentioning.

[cppmsg]

Please don't lean your laptop on the microphone shaft. Every movement causes rumble on the mic.

[KarelDonk]

If you decide to fix std::function and make it const correct, then make it "noexcept correct" as well.

[Voy]

Also vector<bool> example explanation is too complicated. Problem is that vector<bool> stores bools using 1 bit/bool(as bitmasks) and CPUs can not atomically access specific bit.

[Voy]

At 25:50 presenter makes a small but important mistake. [] for maps and sets does not behave like that.

[ennio]

Does he reads a text on his laptop ? That makes the tone of the presentation so much less lively.

[Wren]

1:30 how are concurrent writes of the same data to the same address unsafe? The order of writes is indeterminate, but isn't the result the same?

[yanzhuowang]

At 13:50, how is there no API race? "Whatever" can read "shared_int" while "Thingy" writes to it. There's no guarantee that int write operation is thread-safe on all architectures.

[TheMrKeksLp]

At 4:59 that definitely is a data race. I don't know why he would doubt that. std::string isn't synchronized and in this case is likely going to reallocate while being accessed. That's literally a data race

[arsen]

I'd argue that memcpy is still safe in both those cases because you can still use it in two places, whether it's safe to use it in the same buffer is up to the caller.

[agnesakne]

Guy is only engineer not a sr engineer at google?

[bytefu]

So basically C++ type system is trash and cannot guarantee anything. The biggest problem is that "const" is not transitive. I switched to Rust a few years ago and don't miss C++ a tiny bit.

[xreln]

Been a C++ programmer for 15 years. I don't like the way C++ is going. I'll start using Rust where ever I could

[tommasobonvicini]

Things learned: if you are going for multithreading, you better be data-oriented rather than object-oriented.