3 ms·
Normally you allocate on the stack, so the local function owns the object. You pass (unowned) references to any function you want to call. Those functions are n
by pptr 3y ago
Normally you allocate on the stack, so the local function owns the object. You pass (unowned) references to any function you want to call. Those functions are not concerned about RAII for those references, since they don't own them.
If you want to pass ownership to a different function/thread, you move the object. It's the owner's responsibility to run all the destructors once the caller deletes the object, which RAII does for you.
Granted, this can get undeterministic with the reference counted shared_ptr, since only the last owner of the reference will actually delete the object.
I actually really like RCU for shared access: https://en.m.wikipedia.org/wiki/Read-copy-update https://en.m.wikipedia.org/wiki/Read-copy-update
Deallocation is always done in a background thread and there is no synchronization when reading.
I'm not sure what public libraries are available, unfortunately (I've only used our internal rcu library).
If you want to make efficient use of your zillion cores, you need to make sure single threaded performance is excellent ;)
See Amdahl's law.
But I agree, development velocity is an important factor to consider when choosing languages.
- bsder 3y ago> I actually really like RCU for shared access: https://en.m.wikipedia.org/wiki/Read-copy-update https://en.m.wikipedia.org/wiki/Read-copy-update Deallocation is always done in a background thread and there is no synchronization when reading. I'm not sure what public libraries are available, unfortunately (I've only used our internal rcu library). I do like "eventually consistent" data structures like this where you either see the old one or the new one consistently. However, at that point, you've basically created garbage collection as you've lost your deterministic behavior. (It will get collected--sometime, maybe). They mention the Linux kernel and reference counting specifically, so I'll look at this more in depth. > If you want to make efficient use of your zillion cores, you need to make sure single threaded performance is excellent ;) See Amdahl's law. Erm, that's NOT what Amdahl's law says. "The overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used" Cores mostly spend their time waiting--so improving single core performance isn't a great benefit. In fact, going backwards to lot of simpler cores but lots more cache per core is probably a better benefit. Apple got this. They made the memory system a giant cache and got a huge performance boost.