Re: [boost] Proposal to add smart_ptr to the boost library

From: Sam Partington (sam.partington_at_[hidden])
Date: 2006-01-31 10:42:59

> If you have a policy-based smart pointer and are concerned that developers
> should not have equal access to ST and MT versions, consider making a default
> version that is MT, and leaving it at that.

As long as the default is MT, then yes.  But I'm still not in favour
of PBSP's anyway, but I'll come back to that...

> As far as the code changing and shared objects being passed across threads, if
> you don't understand the ramifications of the design changes you are making,
> you get what you deserve. Just because you're passing shared, lockable
> objects acrosss threads doesn't mean you couldn't get into a deadlock
> situation, for example.

Yes of course, in fact I'd take it further than that. "because you're
passing shared, lockable objects across threads" means you probably
WILL get into deadlock, at some point.... its tricky stuff to get
right.

> > For myself, I would want MT support built in by default.  Its too easy
> > to get wrong to disable it for performance reasons.  And I don't buy
> > that a smart pointer has to be the most efficient thing in the world,
> > how many apps have smart pointer usage as their bottleneck?
>
> Mine. Tested and found with Quantify, and although it was our own policy-based
> smart pointer, the mutex locking was the high peak on the graph. I halved my
> app's response latency by using a single-threaded smart pointer in a
> multi-threaded app.

Which of course is precisely the right time to start making
oprimisations - after you've profiled it and found it to be a problem.
 Still I'm curious about this though, why was your code copying so
many smart pointers?

We've had similar things crop up before, but its always been a poor
choice of algorithm/container/strategy that was causing all the
unnecessary copying,  Fixing the problem rather the symptom has proved
more effective for us.

Also I wonder if you had tried the shared_ptr lock free locking
(huh?!?) you'd have noticed similar (but obviously not *as* good)
perfomance gains?

> I'm not weighing in for support of the proposed code, I'm simply stating that
> I think having access to a shared ST pointer is a good idea in an MT
> environment. And personally I'd prefer a declaration of the policies required
> instead of a macro to change the behavior of specific class.

In general I agree -  I'm dead against macros to enable/disable
features.  But I also find using complex policy classes equally
annoying.  Default template parameters get you so far, but have
problems of their own.

I'd prefer a really explicit separate class called
shared_ptr_no_threads<> or something.  They have very different
behaviour, they should be called different things.

Anyway this debate has been through the mangles several times before,
though this poll on the subject was quite some time ago :

http://aspn.activestate.com/ASPN/Mail/Message/boost/1189836

And in general it seems like people were in favour of a further
development of a PBSP, provided the interface can be got right.  I
wonder what the consensus is now?

Sam