On Monday, 27 November 2017 at 18:29:56 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky
wrote:
Really, shared_ptr is the most contagious primitive of modern
C++.
Not really. Unique_ptr is, though.
To quote MS STL guy “I’m surprised we had no non-inteusive
ref-counted ptr in std lib for so long”.
Going Native videos are full of questions on that.
Yeah, they tend to pretend that C++ is a high level language,
it makes for good talks.
Let me put it this way, C++ is an acceptable low level
language, but it is a rather poor high level language.
So if you talk with people who use C++ as a high level language
you probably see different usage patterns.
I’ve seen a tech giant that works on uber high-performance things
making heavy use of STL, and being fond of C++14 “high-level”
features. I almost took their job offer, it is a nice place.
Comparatively I’ve worked at Google where none of the new goodies
are in use. There are some great things in their “std”, but most
have horrible interfaces and people routinelly discuss how having
at least STL-like primitives would be a huge boon.
Err... That was my point... Only assignment and reset is
protected in shared_ptr, all other methods require manual
sync.
For the benefit of others, let me destroy that:
Oh well, looks like reset and assignment isn't required per the
spec to be protected against races either. That doesn't weaken
my point, the control block is protected but not the methods of
shared_ptr.
I hardly ever use shared_ptr. In practical programming you
That must be why you seriously have no idea how people use it.
Otherwise you’d know that nobody shares a reference to shared
pointer but rather a copy. The whole point of smart pointer is to
avoid naked references.
- shared_ptr allows to share T with thread-safe ownership,
ref-counts are accounted atomically (sharing copies of
shared_ptr pointing to the same block). Copy of shared_ptr is
thread safe and does the count.
Not sure if I follow that description. Shared shared_ptr's are
not thread safe
They are if you use them as intended - value types, that pretend
to be pointers.
a shared control block is. (Technically you share a pointer,
not an object of type T, but that is a minor detail.)
No, you actually share an object and the last one to decrement
the ref will destroy it. Now that is actually thread-safe thanks
to atomic counter.
shared_ptr is pointing to a shared control block that in turn
has a pointer that points to the resource. This control block
contains two counters. These counters are incremented and
decremented atomically.
That is my original point, which you now violently agree with :)
If you access the same shared_ptr from two threads then you
have a potential race condition per the spec.
Just underlines that you don’t understand how it is supposed to
be used.
- atomic_shared_prt would also allow one to initialize a
shared variable (eg global) of type shared_ptr safely from
multiple threads
The main point is that the methods of atomic_shared_ptr are
protected against races.
It is needed because you usually would have have ownership
pointers embedded in a another shared object.
So having a protected control-block is not sufficient outside
the trivial toy-program.
Sufficient for what? Smart pointers are about ownership not
protecting from races.
I also don’t understand what are you trying to prove. My point
was: C++ has to do atomic counting, because it has no concept of
shared vs local.
All of things you’ve said just prove it or are talking about
something I’m not discussing here.
The manual synchronization part comes in if you try to work
with payload T itself. THAT is manual.
No, none of the methods on shared_ptr guarantees that races
won't happen.
Just as you quoted below - all const are, including copy &
destructor.
Since C++ doesn’t see a difference at type level of shared vs
local, there is no thread-local variation of shared_ptr. It
would be too unsafe even for those guys, contrary to what Ola
responses imply.
Sigh. I implied that shared_ptr on a single thread is mostly
useless.
You did imply it’s useless on single thread and not used in
concurrency because you need manual sync. I’d argue you don’t
need a sync to access shared_ptr, you’d need it for object it
points to.
It still solves the ownership and deterministic destruction in
the presense of concurrent shared_ptrs of the same object.
But again - you countered a different point all together, see
above.
But this:
struct OurSharedCache {
shared_ptr<T> something;
shared_ptr<T> somethingelse
}
Not that I talked about it. This has nothing to do with
shared_ptr and/or things I stated originally.
Well I can clearly see misinformation and describe it as such.
See your point about atomic_shared_ptr.
What about it?
«If multiple threads of execution access the same shared_ptr
without synchronization and any of those accesses uses a
non-const member function of shared_ptr then a data race will
occur»
Copy & destruction is actually fine, which you seem to ignore.
Also accessing const methods of payload is fine. New C++ implies
const == thread safe btw, at least in all of STL.
