2 ms·

So, to be clear, you appear to either (a) have a case where there are significant behavior differences between passing by mutable reference versus pointer (and

So, to be clear, you appear to either (a) have a case where there are significant behavior differences between passing by mutable reference versus pointer (and thus _need_ to use a pointer), or (b) are relying on operations to certain types being "atomic" and on the compiler and processor not mangling the code you write without using any explicit concurrency-protecting constructs (e.g. std::atomic<T>) which you believe they would do to a reference argument.

dragontamer 4y ago
Have you read the post in question? Its a good introduction to C++ Concurrency / memory models. atomic<int>* blah; a = *blah; // This is relatively fast. *blah = b; // This is slow: store-release. blah = c; // This is fast, no store-release operation going on. Just a pointer-assignment Anyone dipping down to this level is interested in the performance characteristics of memory barriers. Indeed, the entire point of this exercise is to get faster than std::mutex lock / unlock after all, and squeezing the last ounce of performance out of your code. Indeed, one can argue that when using atomics, the more explicit "store" and "load" functions should be used instead. a = blah->load(); // These two examples are blah->store(b); // arguably the most explicit, preferred choice
- cpgxiii 4y ago
  > Have you read the post in question? Its a good introduction to C++ Concurrency / memory models. Yes, I have. And yes, I am familiar with the C++ concurrency/memory models discussed here. And, to be clear, nothing in the article is doing anything that couldn't be done just as clearly with std::atomic<bool>& as with std::atomic<bool>*. Obviously, if you actually want to be able to assign to the pointer, then you need the pointer form. > Indeed, one can argue that when using atomics, the more explicit "store" and "load" functions should be used instead. Yes, this is the style I strongly prefer. Of course, here it doesn't matter between a = blah->load(); blah->store(b); or a = blah.load(); blah.store(b); and choosing to use the pointer form is often just introducing nullability where you don't need it.
  - kllrnohj 4y ago
    > choosing to use the pointer form is often just introducing nullability where you don't need it. _Nonnull int* whatever; Tada! Nullability avoided. https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeReference.html#nonnull https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeRe...
- bonzini 4y ago
  That's not a store-release, it's a store-release followed by a full memory barrier. A store-release is fast but does not order the store against subsequent loads.

dragontamer 4y ago

Have you read the post in question? Its a good introduction to C++ Concurrency / memory models. atomic<int>* blah; a = *blah; // This is relatively fast. *blah = b; // This is slow: store-release. blah = c; // This is fast, no store-release operation going on. Just a pointer-assignment Anyone dipping down to this level is interested in the performance characteristics of memory barriers. Indeed, the entire point of this exercise is to get faster than std::mutex lock / unlock after all, and squeezing the last ounce of performance out of your code. Indeed, one can argue that when using atomics, the more explicit "store" and "load" functions should be used instead. a = blah->load(); // These two examples are blah->store(b); // arguably the most explicit, preferred choice

cpgxiii 4y ago
> Have you read the post in question? Its a good introduction to C++ Concurrency / memory models. Yes, I have. And yes, I am familiar with the C++ concurrency/memory models discussed here. And, to be clear, nothing in the article is doing anything that couldn't be done just as clearly with std::atomic<bool>& as with std::atomic<bool>*. Obviously, if you actually want to be able to assign to the pointer, then you need the pointer form. > Indeed, one can argue that when using atomics, the more explicit "store" and "load" functions should be used instead. Yes, this is the style I strongly prefer. Of course, here it doesn't matter between a = blah->load(); blah->store(b); or a = blah.load(); blah.store(b); and choosing to use the pointer form is often just introducing nullability where you don't need it.
- kllrnohj 4y ago
  > choosing to use the pointer form is often just introducing nullability where you don't need it. _Nonnull int* whatever; Tada! Nullability avoided. https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeReference.html#nonnull https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeRe...
bonzini 4y ago
That's not a store-release, it's a store-release followed by a full memory barrier. A store-release is fast but does not order the store against subsequent loads.