I just watched again that CPPCON talk:
I’m curious to know if somebody in that forum already considered/tried it?
I have a few remarks about this:
- In my experience (especially for us), it is actually quite often perfectly defined who owns data and who is just reading/updating it. I also found, that by defining who owns what, you end up with better code, because you put energy into getting the design right, instead of using shared_ptr everywhere and letting the ref-count do the thinking for you. This is of course not always the case, and I also use shared_ptrs very often, but I always know, where the origin of the “shared_ptr” lives and I use it to not pay attention when the origin is deleting stuff while e.g. being in an undefined order of a ListenerList.
- When I first read about std::snapshot_source and std::snapshot_ptr I was pretty excited. It sounded like the perfect answer to the problem of using shared_ptr to access data computed by the audio thread or the “rendering tree” that the audio thread is working on while the UI wants to change stuff. However, it is not. std::snapshot_source is not really paying attention to the fact, who is deleting something, while we want to make absolutely sure, that it is not the audio thread calling delete.
Until I came across this: https://github.com/PalmerHogen/Snapshots/blob/main/Include/Snapshots.h – it is doing exactly what I want out of concurrent memory management.
4 Likes
Just in case you missed it, from the same person, about lock free atomic shared pointer:
< https://youtu.be/lNPZV9Iqo3U?list=PLHTh1InhhwT7gQEuYznhhvAYTel0qzl72 >
1 Like
Good point, passing a shared_ptr is an implicit permission to delete the referenced object, and our goal should be to never perform memory management (e.g. deleting an object that is managed by a shared_ptr) on the real-time thread.
5 Likes
In its talk the shared_ptr exposed uses an hazard pointer to protect the control block and defer its reclamation. It explains later that the same approach could be used also for the object owned. I suppose that it could be possible to implement the shared pointer in a way that all the deletions would be done in a background thread… 
i’m not sure it is possible with futur std hazard pointers.
Hey! I’m glad to hear this repo came in handy – the approach is actually very similar to the split-refcount scheme for implementing atomic shared_ptr, but I made no attempt to implement an atomic shared_ptr 
Timur did a great talk on RCU, which is very similar, and his approach works much better if you know how many threads will be reading data in advance
Unfortunately, I needed a way to read data from arbitrarily-many threads (sometimes recursively) without blocking, so packing a refcount and a lookup index into a single value was what I settled on.
1 Like