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.
Also vector example explanation is too complicated. Problem is that vector stores bools using 1 bit/bool(as bitmasks) and CPUs can not atomically access specific bit.
No, it's more than that. He only alludes to this, but the point is that you have no guarantee on the reference type returned by operator[] and how it will mutate the object, whether it's thread compatible. You'd normally expect operator[] to return T&, but for std::vector it's std::_Bit_reference.
@@benjaminbrock1739 all you said is true, but that does not change what I am saying. You can not make vector be space efficient and have nonlocking calls to [2] and [5] that are thread safe. In other words it is not about vector being defective... You can not do this because HW does not allow it. This is the reason why standard also says bitfields are big nono when it comes to thread safety.
Sure, absolutely. But I think the point is that when you're in the wild looking at some random::vector, where you would normally assume operator[] to be thread compatible, you don't really know that unless you examine the reference type it returns and see if it has thread compatibility guarantees or could cause an "API race."
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.
@@yanzhuowang4987 Recall that C++ is a value semantic language, so "Thingy::foo" is taking the int by value and modifying that int parameter is not modifying the original "shared_int," but is modifying a copy of it.
@@yanzhuowang4987 `Thingy` takes the `int` by value, so internally it operates on a copy, not on the shared global. Now you could argue that reading an integer is not portably guaranteed to be atomic (even if alilgned, that's architecture-specific), however the point there was that all operations on the global were reads so performing them without synchronisation is safe.
Usually memory is read or written in atomic units determined by the CPU architecture (32 bit and 64 bits item aligned on 32 bit and 64 bit boundaries is common these days). In this case, what happens depends on the amount of data being written. Let's consider the case of 32 bit atomic read/write cells. If two threads write 32 bits into such an aligned cell, then it is absolutely well defined what happens: one of the two written values is retained. Unfortunately for you (well, the program), you don't know which value. By extremely clever programming, you can actually use this atomicity of reads and writes to build synchronization algorithms (e.g., Dekker's algorithm), but it is faster typically to use architecturally defined locks instead. If two threads write more than an atomic unit (e.g., they both write a 128 bit value), then in fact the atomic unit sized pieces of the values written will be stored in a absolutely well defined way, but you won't know which pieces of which value get written in what order. So what may end up in storage is the value from the first thread, the second thread, or mixes of the bits in atomic unit sizes from both threads. Similar ideas hold for one thread reading, and one thread writing in atomic units, and larger. Basically, you don't want to do unsynchronized reads and writes to memory locations, because you won't know the outcome, even though it may be very well defined by the architecture.
@@knight024 I understand, but look at the code. The pointers are the same. Maybe the problem is that it's a silly toy example. You will have terrible performance because you're in cache snoop hell. You should get the same result as a single-threaded memcpy though.
@@7xr1e20ln8 Array accesses will always generate memory accesses anyway (unless the index is provably constant) because you can't do indirect addressing on registers. Volatile would just give you a guarantee that the array accesses aren't reordered with respect to each other within a single thread of execution, and doesn't help us with this multithreaded example.
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
The standard specifies that a data race happens when two operations read and write from or to the same memory location concurrently. It does not specify anything about objects, and so, because std::string is an abstraction and not a built-in type, it is not a data race in the sense of the Standard. You would need to look underneath the hood to check if there is actually a data race. The example just aims to show that the standard does not comtemplate properly all cases in the definition, hence the definitions the people in Google use internally
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.
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.
I second that. Don't know if Rust is the answer (but that's not my point). With any new 1x, 2x versions sooo many pitfalls came with the new features and just nothing got simpler if you try to use it seriously in production code. Nicolai Josuttis' talk highlights one aspect, and if you look into others aspects it's just the same can of worms. Might be great for library implementers but for application development it's just a whole bunch of rules "Don't do that" you have to add with each new standard version. And that's just frustrating.
@@andreasfett6415 I would not fully agree. Some of the new additions in 0x (including lambdas) are pretty handy. But what I see in 17x looks mostly creepy. Instead of adding useful helpers like coroutines or async/await (maybe extending futures with nicer background thread interaction) they started inventing hairy things like string_view.
@@DuRoehre90210 I totally agree with you, that some of the additions to 0x are useful. But while lambdas are indeed very nice, they add their own set of problems you have to keep in mind (eg scoping issues). So again a set of rules which say "Don't do that". That's all nice for people that just have to learn the diff, but try using young programmers on C++ code bases. With each new standard version the learning curve just becomes steeper and code reviews more painful. As for coroutines, I already have nightmares about debugging code using them unless the gdb people come up with something really smart.
I've seen a decent amount of CppCon lectures on youtube lately, and basically half of them describe conventions you ought to follow in order to avoid problems which wouldn't compile in the first place in Rust. Data races (or "API races") is one such thing.
@@MasterHigure I'm not a Rust programmer, but do those come with algorithmic restrictions? E.g. there are some things you can't do* at all in Java because it is sometimes unsafe even if your implementation is perfectly safe and correct. *in any reasonable way
Definitely a talk that has to be watched more than once...
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.
What is a "const call"?
If you decide to fix std::function and make it const correct, then make it "noexcept correct" as well.
Please don't lean your laptop on the microphone shaft. Every movement causes rumble on the mic.
At 25:50 presenter makes a small but important mistake. [] for maps and sets does not behave like that.
He discusses it during comments around 50:00.
Also vector example explanation is too complicated. Problem is that vector stores bools using 1 bit/bool(as bitmasks) and CPUs can not atomically access specific bit.
No, it's more than that. He only alludes to this, but the point is that you have no guarantee on the reference type returned by operator[] and how it will mutate the object, whether it's thread compatible. You'd normally expect operator[] to return T&, but for std::vector it's std::_Bit_reference.
@@benjaminbrock1739 all you said is true, but that does not change what I am saying. You can not make vector be space efficient and have nonlocking calls to [2] and [5] that are thread safe. In other words it is not about vector being defective... You can not do this because HW does not allow it. This is the reason why standard also says bitfields are big nono when it comes to thread safety.
Sure, absolutely.
But I think the point is that when you're in the wild looking at some random::vector, where you would normally assume operator[] to be thread compatible, you don't really know that unless you examine the reference type it returns and see if it has thread compatibility guarantees or could cause an "API race."
Actually, most CPUs do support atomic bit set/clear operations, though obviously at a performance cost.
@@MatthijsvanDuin They also support atomic OR and AND which are enough to implement a lockless bitset
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.
After seeing the next slide, I think he is missing a "const" in the "Thingy::foo" function signature.
@@yanzhuowang4987 Recall that C++ is a value semantic language, so "Thingy::foo" is taking the int by value and modifying that int parameter is not modifying the original "shared_int," but is modifying a copy of it.
Both shared int parameters are local copy of global int, so there's indeed no race
@@yanzhuowang4987 `Thingy` takes the `int` by value, so internally it operates on a copy, not on the shared global.
Now you could argue that reading an integer is not portably guaranteed to be atomic (even if alilgned, that's architecture-specific), however the point there was that all operations on the global were reads so performing them without synchronisation is safe.
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?
Usually memory is read or written in atomic units determined by the CPU architecture (32 bit and 64 bits item aligned on 32 bit and 64 bit boundaries is common these days).
In this case, what happens depends on the amount of data being written.
Let's consider the case of 32 bit atomic read/write cells.
If two threads write 32 bits into such an aligned cell, then it is absolutely well defined what happens: one of the two written values is retained. Unfortunately for you (well, the program), you don't know which value. By extremely clever programming, you can actually use this atomicity of reads and writes to build synchronization algorithms (e.g., Dekker's algorithm), but it is faster typically to use architecturally defined locks instead.
If two threads write more than an atomic unit (e.g., they both write a 128 bit value), then in fact the atomic unit sized pieces of the values written will be stored in a absolutely well defined way, but you won't know which pieces of which value get written in what order. So what may end up in storage is the value from the first thread, the second thread, or mixes of the bits in atomic unit sizes from both threads.
Similar ideas hold for one thread reading, and one thread writing in atomic units, and larger.
Basically, you don't want to do unsynchronized reads and writes to memory locations, because you won't know the outcome, even though it may be very well defined by the architecture.
@@knight024 I understand, but look at the code. The pointers are the same. Maybe the problem is that it's a silly toy example.
You will have terrible performance because you're in cache snoop hell. You should get the same result as a single-threaded memcpy though.
Hmm, could be volatile memory
@@7xr1e20ln8 Array accesses will always generate memory accesses anyway (unless the index is provably constant) because you can't do indirect addressing on registers. Volatile would just give you a guarantee that the array accesses aren't reordered with respect to each other within a single thread of execution, and doesn't help us with this multithreaded example.
important
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
The standard specifies that a data race happens when two operations read and write from or to the same memory location concurrently. It does not specify anything about objects, and so, because std::string is an abstraction and not a built-in type, it is not a data race in the sense of the Standard. You would need to look underneath the hood to check if there is actually a data race. The example just aims to show that the standard does not comtemplate properly all cases in the definition, hence the definitions the people in Google use internally
Does he reads a text on his laptop ? That makes the tone of the presentation so much less lively.
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.
Guy is only engineer not a sr engineer at google?
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.
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
I second that. Don't know if Rust is the answer (but that's not my point). With any new 1x, 2x versions sooo many pitfalls came with the new features and just nothing got simpler if you try to use it seriously in production code.
Nicolai Josuttis' talk highlights one aspect, and if you look into others aspects it's just the same can of worms.
Might be great for library implementers but for application development it's just a whole bunch of rules "Don't do that" you have to add with each new standard version. And that's just frustrating.
@@andreasfett6415 I would not fully agree. Some of the new additions in 0x (including lambdas) are pretty handy. But what I see in 17x looks mostly creepy. Instead of adding useful helpers like coroutines or async/await (maybe extending futures with nicer background thread interaction) they started inventing hairy things like string_view.
@@DuRoehre90210 I totally agree with you, that some of the additions to 0x are useful. But while lambdas are indeed very nice, they add their own set of problems you have to keep in mind (eg scoping issues). So again a set of rules which say "Don't do that". That's all nice for people that just have to learn the diff, but try using young programmers on C++ code bases. With each new standard version the learning curve just becomes steeper and code reviews more painful. As for coroutines, I already have nightmares about debugging code using them unless the gdb people come up with something really smart.
I've seen a decent amount of CppCon lectures on youtube lately, and basically half of them describe conventions you ought to follow in order to avoid problems which wouldn't compile in the first place in Rust. Data races (or "API races") is one such thing.
@@MasterHigure I'm not a Rust programmer, but do those come with algorithmic restrictions? E.g. there are some things you can't do* at all in Java because it is sometimes unsafe even if your implementation is perfectly safe and correct.
*in any reasonable way
Things learned: if you are going for multithreading, you better be data-oriented rather than object-oriented.
Damn, he is deaf as hell!
No its the ridiculously thick accents, completely incomprehensible questions, and them not making _any_ effort to speak clearly.