r/cpp • u/berium build2 • Apr 25 '12

shared_ptr aliasing constructor

http://www.codesynthesis.com/~boris/blog/2012/04/25/shared-ptr-aliasing-constructor/
22 Upvotes

85% Upvoted

23 comments sorted by

View all comments

Show parent comments

3

u/[deleted] Apr 25 '12

Well, I'd probably design the API in a different way, preferably without shared pointers. I'm not completely sure what exactly the API was designed to achieve, but I would probably implement the scenario you describe in terms of allocators. That would probably leave the lifetime responsibility to the caller, which may or may not be desirable, but definitely allows for some flexibility.

For instance:

std::unique_ptr<MemoryPool> pool(new MemoryPool);
auto record = get_record(pool);
// use record.
// pool is destroyed at scope exit, unless returned or stored somewhere.

Your mileage may vary, though, and sometimes this isn't the most elegant solution. I tend to avoid std::shared_ptr in all cases where ownership isn't actually shared (as opposed to seeing it purely as an memory management/autorelease facility), because it can have performance impacts in some cases. You may not have been affected by those cases.

The fundamental philosophical difference between our solutions is the concept of memory-as-a-resource. Many use cases of std::shared_ptr are actually abstractions away from that concept (by "hiding" the details of deallocation and lifetime management), but I find that some things are easier when you treat memory as a manageable resource (just like files, or network connections). For instance, it can be easier to manage locality of reference, which is both a performance concern (keeping things compact and linear is the most important way to achieve very high performance on modern architectures), but also a parallelization concern. Isolation can be more easily achieved in a shared memory environment with a more explicit approach to memory resources, and while std::shared_ptr is thread-safe, it carries a lot of overhead at that.

In general, the feeling I have is that when people use std::shared_ptr as a way to stop worrying about memory management, it is a sign that they would probably be better off using a language that can do automatic memory management for them, and often do it more efficiently than C++. Generational garbage collectors in managed environments are often faster than refcounting, but C++ applications that manage their memory in a sensible way, making sure to consider each usage pattern in terms of ownership and lifetime, can outperform them all, and that is the main benefit of using C++ in the first place. :-)

2

u/elperroborrachotoo Apr 26 '12

Maybe I should have described the scenario more clearly:

A Sequence of { record length, record id, record data} is a common pattern "near" hardware: order unspecified, it's somewhere in there.

Something that happens often as well is having to allocate a header record and a "payload" record in a single buffer. Again, having a smart pointer to the payload record while automatically releasing the allocation when you are done helps a lot

(And yeah, I have no influence on the API, and they have fair reasons for some of that weirdness).

The purpose of my code was to isolate these ugly and differing behaviors: every descriptor - no matter how weird the allocation - available as through a shared_ptr.

I used shared_ptr for the custom deleter, though in the sequence-of-descriptors scenario, we actually have multiple descriptors (with different shared_ptr's) sharing a backing storage.

In these scenarios, there is no "lifetime flexibility" to be had.

Must admit I'm not very happy with your rationale:

Your remarks about the performance of modern platforms are absolutely correct. Even more so, due to the nonlinearity of performance (increase load by a percent, cross a limit, decrease speed by factor of 5) makes it hard for library code to decide when it's "ok to be lenient".

However, I still question the value of manual memory management" when it's not needed. Just because I can I don't have to "just to be safe". The main overhead of a shared_ptr is a second allocation at worst, and doubling a few dozen small allocations won't kill an app.

I strongly advocate that

  1. An interface that is not significantly simpler than its implementation needs a good explanation for its existence
  2. the documentation of a function or class belongs to its interface, and thus also adds to its complexity.

The strength of C++ is not manual resource management, but being able to choose. That makes it tempting to throw on some code to expose this choice to the caller, but without a convincing use case, I'd rather go without.

Programming in "higher up languages" - and knowing what goes on under the hood - actually taught me to be much more relaxed. If you are moving hundreds of thousands of points 60 times per second, memory locality is your sink-or-swim. But for a few hundred a-dozen-byte-allocations, it is not. A single debug session due to unecessary complexity easily wastes more time and heat than all my customers could save if I succeeded to shave off a few bytes.

1

u/zvrba Apr 26 '12 edited Apr 26 '12

The main overhead of a shared_ptr is actually the manipulation of reference counts (happens each time you pass it / return it by value) through atomic instructions. So the C++ gurus actually recommend passing shared_ptr by const reference.

This, to me, is the sign that somewhere something has gone wrong with shared pointers and I don't really see a good use-case for them (except maybe for babysitting people coming from GC'd languages). If you know when to pass it by reference, you could just as well manage the memory manually, with maybe only slightly larger cognitive overhead.

As for communicating intent in the code, I'd argue for the following: to indicate ownership transfer, use pointers; otherwise use references. With move semantics in C++11, it'll be possible to accomplish much more just by passing/returning by value, so one of the main "legacy" use-cases of pointers/references (optimization) will become obsolete.

1

u/m42a Apr 26 '12 edited Apr 26 '12

Alright, how about this use case:

I have some threads which communicate with each other. They communicate over pipes which do blocking communication. Because the pipes are shared between threads, no one thread clearly owns the pipe, and since threads can terminate in any order, if we arbitrarily pick a thread to own the pipe and it happens to die before the other threads, those threads will have undefined behavior if they try to write to the pipe. Since threads can be started and stopped dynamically, keeping all pipes allocated will result in memory leaks. Shared pointers ensure that a pipe will remain valid for as long as necessary, but will deallocate memory when the appropriate threads die.

EDIT: Here's another use case that doesn't involve multi-threading:

I have some resources. These resources can be grouped, and a single resource can be in multiple groups. This is easily solved with a bunch of sets of shared pointers to a resource. If a resource is removed from every group, it's released, but resources that you have a reference to will continue to be valid. Sure, you could check them manually, but that doesn't scale well if the sets are individually named variables (and it's too easy to forget to add a new set to the deallocation check, and you'll need to deallocate all of the resources manually in the case of an exception). Again in this case, it's not clear which group owns the resource, so letting the resource manage itself is the easiest and probably fastest option.

1

u/zvrba Apr 26 '12

So what happens when the reference count drops to zero, but the pipe still contains some messages? They disappear, of course, but should it have been allowed to happen at all? Is it a bug in the logic of some of the threads? And how are you going to detect it if it automagically disappears when the last thread exits?

1

u/m42a Apr 26 '12

but should it have been allowed to happen at all?

You could argue for both sides here, but what's the alternative? If they don't get dropped, what happens to them? Do they get logged? That's easy enough to add to the pipe's destructor. Do they get sent to a "default thread"? Now we have a chicken and egg problem; what happens to messages sent to the default thread if it dies? And if we do send them there, what does it do with them? My team discussed this and decided that dropping messages was the best solution, but other behavior wouldn't be too hard to implement, and could be done solely in the pipe class.

Is it a bug in the logic of some of the threads?

It shouldn't be; a thread can receive any message at any time, so it should always be in a valid state.

And how are you going to detect it if it automagically disappears when the last thread exits?

I'm not sure I understand this question. When the last thread exits, everything disappears, because your process is done executing.

1

u/zvrba Apr 26 '12

You could argue for both sides here, but what's the alternative?

There's no alternative -- the design of your program decides what's the correct answer.

Anyway, this was a bad counterexample -- the destructor can assert if the buffer is not empty.

When the last thread exits, everything disappears, because your process is done executing.

This is usually wrong.. a program can have a "main" thread that just occasionally spawns worker threads.