Boost.Signal2 performs too many locks in a multi-threaded environment where the life cycle of the source and target are the duration of the program

[Dave Gotwisner <dgotwisn@…>]

Boost.Signal2 requires that the receiver be a shared_ptr, or a weak_ptr.

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.

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.

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.

Because of the proprietary nature of our code, I can't attach a sample.