[Kototama]

Multithreaded C++ programming without bugs is still very hard. There was an interview on Mozilla and why they started Rust and everytime they had some path in the code with threads, they found some concurrency issue. I can't find the link right now.

Edit: I think it's in this podcast https://corecursive.com/013-rust-and-bitter-c-developers-wit...

[PaulDavisThe1st]

> Multithreaded C++ programming without bugs is still very hard.

Multithreaded programming without bugs is hard in any language, unless the language completely cripples your ability to do certain things that tend to be where the bugs can creep in.

If you religiously stick to the rules (e.g. mutexes around all variable use, mutexes and condition vars used correctly), you will not have bugs. The problems come because people do not religiously stick to the rules, because their language doesn't require them too.

The problem is that if you are forced to follow all the rules, then certain things become impossible, such as lock-free programming (even the simple single-reader, single-writer FIFO). The use of memory barriers to create provably safe lock-free code is outside the scope of regularized multithreaded programming, and since it's very very hard to get that write, but people want to try it anyway, that's where things go wrong.

Just use things the way you're supposed to and you won't have bugs with this.

[lawn]

> Just use things the way you're supposed to and you won't have bugs with this.

If we humans just learned to use things we're supposed to, we would never have null pointer exceptions, issues with use-after-free nor buffer overflows. Heck, we should all just use goto while we're at it, all it takes is to religiously stick to the rules!

[PaulDavisThe1st]

Reasoning about null ptr, use after free, buffer overflows is tricky, because you cannot determine whether you've done the right thing by "just reading the code".

If you are doing multithreaded programming, and there's a variable shared among threads, and there's a read or write of the variable without a mutex in sight, you've done it wrong.

Yes, the mutex owner could be a caller several layers up the stack. Sometimes that's a legitimate design, and if you know what you're doing your function/method names will reflect the fact that the lock is already held. If you don't know what you're doing, you should avoid that design and lock the mutex in the same scope as the read/write.

And of course, using RAII with C++ (or anything else that supports it) makes this sort of thing easy to do.