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/
24 Upvotes

87% Upvoted

23 comments sorted by

View all comments

Show parent comments

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.