Precise GC state

[Dmitry Olshansky]

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.