On Mon, 8 Jul 2019 at 13:19, Oleg Endo <oleg.endo@xxxxxxxxxxx> wrote: > > On Sun, 2019-07-07 at 22:00 +0100, Jonathan Wakely wrote: > > On Sun, 7 Jul 2019 at 21:18, Paul Smith <psmith@xxxxxxx> wrote: > > > > > > On Sun, 2019-07-07 at 20:31 +0100, Jonathan Wakely wrote: > > > > > It might be useful to at least discuss this in the > > > > > docs, although I suppose systems using glibc <2.17 are getting > > > > > more > > > > > rare every day. > > > > > > > > There are performance penalties to using it too, so it's not just > > > > a > > > > case of saying "hey, you should use this!" > > > > > > > > If you link to librt on GNU/Linux then you get a dependency on > > > > libpthread which causes libstdc++ to always assume your program > > > > is > > > > multithreaded, and use atomic ops for reference counting even in > > > > single-threaded programs. > > > > > > Yes, that information is presented in the docs, which is good. But > > > I > > > think the other side of this (that selecting "rt" on older glibc > > > implementations will give a 22-24% performance increase when > > > calling > > > steady_clock() / system_clock()) should also be mentioned. > > > > > > Unless you're building for a very specific target/need, you likely > > > will > > > want your compiler to be able to be able to create multi-threaded > > > programs. > > > > I'm not sure what you mean here. The compiler is able to create > > multi-threaded programs either way. The issue is whether > > single-threaded programs pay a cost that's only needed by > > multi-threaded programs or not. With the "rt" option you get a > > compiler that is not able to use a libstdc++ optimisation normally > > enabled for single-threaded programs. > > Even with single-threaded programs there could be async signal > handlers.... and on MCU/baremetal targets we've got interrupt handlers, > which are conceptually the same. I'd expect shared_ptr to just work > there, too. What do you base that expectation on? Only accesses to std::sig_atomic_t variables are safe in signal handlers. > But if all it takes is linking in pthread, that's no > problem. It's orthogonal to this discussion anyway. The --enable-libstdcxx-time=rt option can cause all ref counting to be atomic, which isn't going to make the signal handler case any worse.
