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

From: Bud Millwood (budm_at_[hidden])
Date: 2006-01-31 08:07:18

> Shared_ptr will only include threading support in a multithreaded
> environment.  So you only pay for it if there is a possibility of
> shared_ptr's being shared across threads.
>
> The problem with letting the developer decide on a per ptr basis
> whether or not they need MT support is that users (myself included of
> course) tend to make poor choices.  Also code changes, a design which
> didn't share ptr objects across threads may well end up sharing ptr
> objects as the code matures/is maintained.

I beg to differ. I don't make poor choices on a per-pointer basis. <heh>

We typically use single-threaded policy-pointers in multi-threaded apps when 
we need the performance and know that the objects we're handling are either 
safely tucked away in that operating thread, or can be deep-copied across 
threads using some external synchronization.

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 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.

> 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.

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.

- Bud