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