Precise GC state

[Ola Fosheim Grøstad]

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.

>> 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 
usually need to exchange more than a single entity so you need 
manual sync anyway.


> - 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, a shared control block is. (Technically you 
share a pointer, not an object of type T, but that is a minor 
detail.)

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.

If you access the same shared_ptr from two threads then you have 
a potential race condition per the spec.

> - 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.

> 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. And in general you usually want to access more than one 
unit in a critical section.

So in C++ you typically need manual sync.

There are no suitable language features to get around that in C++ 
and library features are inadequate in the general sense.

Go and Pony have language features that are helpful. C++ doesn't.

> 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.

But this:

struct OurSharedCache {
    shared_ptr<T> something;
    shared_ptr<T> somethingelse
}

Not safe.


> 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»

http://en.cppreference.com/w/cpp/memory/shared_ptr

«The class template atomic_shared_ptr provides thread-safe atomic 
pointer operations over a std::shared_ptr.»

http://en.cppreference.com/w/cpp/experimental/atomic_shared_ptr