4 ms·
std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situ
by berkut 7y ago
std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situations.
- usrnm 7y agoOn the other hand, not using atomics in heavy multithreaded code is just a recipe for disaster. The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.
- jcelerier 7y ago> The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill. On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread. If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitely.
- masklinn 7y agoOne of the advantages of rust is its ability to segregate safe-to-share (between concurrent contexts) and not so, at compile time. While it can’t (yet?) be generic over them, it lets you use the non-atomic Rc in thread-bound structures and know this is never going to be shared between threads, whereas the more expensive Arc can have handles be moved from one thread to an other.
- safercplusplus 7y agoCounterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard. [1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-counting-pointers https://github.com/duneroadrunner/SaferCPlusPlus#reference-c... [2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncsharedv2readwriteaccessrequester https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare... [3] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool