I'm note sure exactly what you mean by "the C++ memory model" but I'm pretty sure that it does not underlie Rust's model of threading unless you just mean that Rust assumes a Von Neuman architecture. First of all the stacks of Rust threads are segmented, unlike those of C++ threads, so there's one feature that cannot be duplicated by a C++ library.
But more importantly, Rust doesn't allow any shared mutable state, meaning that all the synchronization primitives C++11 provides can be used by the language automatically by the language on your behalf. Of course, nothing prevents someone from creating a library in C++ that does the same thing, but there's no way for the compiler to enforce the clean thread-wise separation of state and if you've forgotten to get rid of some pointer to an object you're passing to another thread you won't know about it potentially until you're debugging it in production. Also there are a number of threading optimizations that the Rust compiler can make with re-ordering or eliding memory accesses that the C++ compiler can't.
"Or are you claiming that C++ is in fact particularly well suited for parallel development and inherent avoidance of data races?"
I answered the c++ memory model was certainly sufficient and the implementation was left to libraries until C++11 when it was standardized. I did not mean to imply that the c++ memory model underlies that of Rust.
And I agree these are great points to illustrate. Would make some great text to use on their introduction page in place of the trolling. Still, I believe the same deficiency exists regarding compiler enforcement for Rust since the "unsafe" keyword allows for manual management, correct? I can't intelligently comment on the compiler optimizations to which you refer. If you could provide some reference to further analysis? Regardless, the two same two people are downvoting my comments so I won't be commenting further.
Although you clearly understand, I'll throw in the token links for people who may not understand what a memory model is or how the c++ memory model has been formally standardized. To be honest, I don't know why I bother.
But more importantly, Rust doesn't allow any shared mutable state, meaning that all the synchronization primitives C++11 provides can be used by the language automatically by the language on your behalf. Of course, nothing prevents someone from creating a library in C++ that does the same thing, but there's no way for the compiler to enforce the clean thread-wise separation of state and if you've forgotten to get rid of some pointer to an object you're passing to another thread you won't know about it potentially until you're debugging it in production. Also there are a number of threading optimizations that the Rust compiler can make with re-ordering or eliding memory accesses that the C++ compiler can't.