[boost] Re: shared_ptr and BOOST_DISABLE_THREADS

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-04-24 18:20:00

On Apr 24, 2004, at 2:04 PM, Peter Dimov wrote:

>> why are we trying to built thread-safety into shared_ptr? There is 
>> good
>> saying that drove C++ to the point where we are right now: "do not pay
>> for what you do not use". If I'm willing to provide own 
>> synchronization
>> for shared pointers,
>
> You can't. Not unless you control the entire program and you can 
> determine
> with certainty which shared_ptr instances share ownership at every
> particular moment.

Actually I'm not convinced about this.  I have the same concerns as 
Bronek.  They are only concerns.  I am not sure of myself.  But here's 
a data point:

In the Metrowerks std::tr1::shared_ptr I give the option to the client 
whether or not shared_ptr contains a mutex (via a #define flag).  This 
decision can be made independent of whether the entire C++ lib is 
compiled in multithread mode or not.  And at the same time I use 
shared_ptr in the implementation of std::locale.

In the std::locale implementation I am careful to wrap each use of the 
locale implementation with a mutex lock.  I believe I would have to do 
this whether or not shared_ptr protected its count.  And yet 
std::locale is just a library, not an application.

Perhaps a more correct statement is that if you expose a shared_ptr as 
part of your interface, and advertise that multiple threads can operate 
on copies of that exposed shared_ptr, then shared_ptr must be 
internally protected.  But if your shared_ptr is used as an 
implementation detail within your library, an internal mutex is not 
necessarily beneficial, and may even be a handicap.

-Howard