Smarter Cpp Atomic Smart Pointers - Efficient Concurrent Memory Management - Daniel Anderson CppCon
Вставка
- Опубліковано 16 лип 2024
- cppcon.org/
---
Smarter C++ Atomic Smart Pointers - Efficient Concurrent Memory Management for Everybody - Daniel Anderson - CppCon 2022
github.com/CppCon/CppCon2022
Memory management is hard, especially for concurrent code, even for concurrency experts. To make it more manageable, C++ programmers almost always rely on high-level abstractions such as smart pointers and deferred reclamation techniques such as hazard-pointers and RCU that offer to reduce the burden. These abstractions, however, come with many tradeoffs. In this talk, we will discuss recent library solutions that aim to combine the advantages of these techniques to produce a solution that is as easy to use as smart pointers but as fast and scalable as deferred reclamation techniques. We aim to convince the audience that scalable concurrent code with the performance of expert-written code can be written using abstractions as simple as smart pointers.
As a starting point, we will discuss existing techniques and their tradeoffs. Smart pointers, such as the recently standardized atomic shared pointer, drastically reduce programmer effort, but existing implementations do not scale and result in low-performance code. Advanced deferred reclamation techniques such as hazard-pointers and RCU, as included in the latest concurrency TS, are highly scalable but very subtle and difficult to use correctly. We will show that they are a common source of memory bugs even when used by concurrency experts.
The main part of the talk will then focus on several recent library interfaces that aim to combine the best of both worlds from atomic smart pointers and deferred reclamation techniques. We will also discuss some techniques that can be used to efficiently implement these interfaces and explore their performance.
---
Daniel Anderson
Daniel is a fifth-year PhD candidate in the Computer Science Department at Carnegie Mellon University. He is interested in the design of fast parallel algorithms and likes to write C++ libraries that make parallel computing easier and more accessible. He is a recipient of a best paper award from the ACM Symposium on Parallelism in Algorithms and Architectures conference.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #memorymanagement - Наука та технологія
A good speaker. Hope to listen to him again in the future.
This is an absolute game changer for concurrent data structures. Great talk!
Best talk I've seen in a long while.
Phenomenal speaker and great talk
Amazing, this is like sqrt(complexity(HazardPointer) + complexity(RCU)) 😅. Great talk!
A very nice talk, easy to understand, thank you very much.
A very concise, good illustrated and informative talk. Thank you!
Wow. Such an amazing talk!
Exquisite explanation and slide details!
Damn, I wish I was this smart haha
Great talk, thanks for clear presentation
Very cool
Just wondering whether we also need the *deferred_unique_ptr* counterpart?
What overhead this deferred logic will have in a single threaded application compared to the shared_ptr? If the compiler could reason about the threading environment and optimize out the "please don't delete it if someone else uses it" in the case of object living in a single thread, then it might make sense to add this logic straight to the shared_ptr itself! Great talk by the way.
Locks aren't bad per se. They allow OSes to detect dependencies between threads and wake up threads holding the lock to hopefully release it quicker.
When I announce a hazard pointer, how do I get a guarantee that garbage collector will see my announcement in time? How to prevent that they see the bulletin board in a state just before I announced my hazard pointer? I am assuming there is a nonzero latency i.e. "travel time" between me announcing it, and the announced data becoming visible to the other thread.
45 minutes in: How come the `protected_ptr->increment_ref_count();` call does not cause cache trashing like in the shared_ptr case? Yes the decrement is being deferred but nothing is said of the increment. Is it in separate memory for different threads and the deferred decrement goes through that?
I belive it is related to the question at 59:15. You don't use the load() method during tree read.
This snapshot-pointer is basically what I started try implementing about 2 months ago: an owning observable pointer ( both for unique and shared ownership).
But my attempt so far is using a lock cause i want to guarantee that if the actual owner of the resource (or all sh ared owners) end their lifetime the resource also is destroyed.
It allows me to have a unique owner in 1 thread but still being able to acces the resource from another thread, while having the guarantee that the resource is valid at any access.
16:34, just attach a callback to the reference counter, example:
struct GC { ... };
sem_t sem;
class Gc
{
struct GC **m_gc;
public:
Gc() { m_gc = new struct GC*; *m_gc = new struct GC; ... }
Gc( Gc *_gc ) { m_gc = _gc->m_gc; ... }
~Gc() { sem_wait( &sem ); if ( !(*m_gc) ) { sem_post( &sem ); return; } *m_gc = NULL; sem_post(&sem); ... }
}
struct A { ... };
void delete_A_callback( void* ud ) { struct A *a = ud; delete a; }
class B
{
struct A *m_a;
gcsem_t *m_sem;
public:
B()
{
m_a = new A;
m_sem = gc::create( m_a, delete_A_callback );
}
B( B* b )
{
m_a = b->m_a;
m_sem = b->m_sem;
m_sem->increase_refc();
}
~B() { m_sem->decrease_refc(); }
}
m_sem::decrease_refc() is then responsible for deleting m_a, as for itself the gc is responsible for deleting it during collection when it sees the reference count as less than 1, assuming it hadn't been re-assigned to another object prior to that.
The global semaphore is for ensuring the read occurs after the pointer has been updated by the thread responsible for deleting the GC, the same semaphore can be used for making sure the pseduo semaphores are deleted before another thread can learn they even exist, this is both fast and flexible, as long as you don't try to delete the pointers directly then no issues will occur
Interesting. I find it hard to wrap my head around this though, as there are quite a few names used that aren't defined and I find it hard to come up with the intent for all of them at the same time. Also, GC and Gc is confusing. Is GC intended to be global and Gc in a scope around some algorithm somewhere?
"Just [~50 lines of code]"
I'm exaggerating for humor.
I'm sure it's a good solution some of the time, and is justifiably prefixed with a "just" to imply that it's simple/easy/clear enough to not need whatever the alternative was.
I sometimes wonder how Linux, Mac and Window kernel work just fine without all this expert things.
Linux uses RCU
What do you mean? The Linux kernel has lots of usage of the RCU. I personally can talk only for the network stack of Linux but it for sure has lots of usage of the different RCU flavors. However, according to the inventor of the RCU, who is well known in the Linux kernel community and who also has a proposal for RCU in the C++, the usage of the technique in the Kernel grows steadily.
Amazing talk content and good presentation.
The only thing that really got on my nerves was the large amount of repetition like the audience is a 5 year old with ADHD.
Isn't this talk addressed to the potential implementers and the people that want to adopt this idea FOR their junior developers and not the junior developers themselves?
Maybe I am too sensitive...
I think it was more to convince the junior developers that they want this rather than doing hazard/rcu themselves, and to convince the experts that it will improve things for them by not having junior devs making bugs for them while not losing unreasonable performance. I don't think this talk was meant for people who want to implement this, but to adopt it with a tiny shout out that he is open to contributions from the very few people like yourself who want to implement a production version. He was selling the concept, not teaching how to implement it, and it made for an incredibly accessible talk for all levels.
But not everyone in the conference are familiar with these concepts and the nuances of it i imagine.