21–30 of 50 posts
[0] https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
Earlier quoted context omitted.
That was mostly meant as irony/a joke, but I admit that's not really clear from the text... For the sake of clarity, if you need thread-safety, probably best to just use std::shared_ptr / std::weak_ptr.
It's a common misconception that std::shared_ptr is thread safe. The counter is thread safe, but the actual shared_ptr itself can not be shared across multiple threads. There is now atomic_shared_ptr which is thread safe.
Earlier quoted context omitted.
atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.
People assume non-existent guarantees such as?
Earlier quoted context omitted.
> but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention Why would there be contention in a single threaded program?
atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.
> For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention).
A single-threaded program will not have cross-core contention whether it uses std::atomic refcounts or plain integer refcounts, period. You're right that non-atomic refcounts can be anywhere from somewhat cheaper to a lot cheaper than atomic refcounts, depending on that platform. But that is orthogonal to cross-core contention.
> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader. Why intentionally design a worse alter…
We were happy to use unique_ptr, however.
std::span is another option. Especially when paired with libc++'s hardening mode(s). Apparently, Google has deployed them in production.
Earlier quoted context omitted.
atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.
OP specifically mentioned contention, though -- not marginally higher cost of atomic inc/dec vs plain inc/dec. > For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention). A single-threaded program will not have cross-core contention whether it uses std::atomic refcounts or plain integer refco…
Earlier quoted context omitted.
> isn't everything multi-threaded these days.. There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".
weak_ptr supports this -- it's only mt-safe if you specialize it with std::atomic