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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk