Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at