Slowness from thread-safe shared_ptr

Jonathan Wakely jwakely.gcc@gmail.com
Tue Nov 6 14:55:00 GMT 2007


On 06/11/2007, Chris Jefferson <chris@bubblescope.net> wrote:
> I recently mapped some code from my own implementation of shared_ptr
> to the tr1 implementation, and found a quite disappointing level of
> slowdown (~15%). Profiling seems to show this is entirely down to the
> thread-safeness of shared_ptr. As I don't use threads, this is a bit
> annoying. Is there a general way of turning off the thread safety, or
> should I have to keep a separate stripped copy?

Hi Chris,
see http://gcc.gnu.org/ml/libstdc++/2007-10/msg00180.html

In theory you could select the non-threadsafe lock policy, but in
reality that still uses the atomic ops.  I proposed some additional
specialisations for the non-threadsafe policy which avoid the
fully-fenced atomic builtins.

However, if you don't use threads, why are you seeing threadsafe ops
used by shared_ptr?  The _S_single policy should be selected when GCC
is configured with thread-model: Single or when there is only a single
thread of execution in the program.

Jon



More information about the Libstdc++ mailing list