https://svn.boost.org/trac10/ticket/10163 <p> Boost.Signal2 requires that the receiver be a shared_ptr, or a weak_ptr. </p> <p> If the life cycle of the receiver is the length of the program (ie, created rather than new'ed as a global object), there is no need to reference count the pointer. On Linux/X86_64, the act of making it a shared pointer (to protect it from going away underneath us) causes an atomic increment and decrement of the reference counter, which causes high CPU utilization in the atomic lock/unlock when performing lots of signals in parallel across multiple threads. </p> <p> It would be nice to have a non-shared_ptr interface to eliminate the refrence count bottle neck, as the management of the pointer is higher overhead than actually doing the signal, in many cases. </p> <p> This was found with a program that has multiple threads signalling very small objects at a very high rate, and looking at the underlying system with both gprof and pprof. In our test case, 48% of the gprof time was spent in the atomic lock/unlock/test code. </p> <p> Because of the proprietary nature of our code, I can't attach a sample. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10163 Trac 1.4.3