Fast sigblock (AKA rtld speedup)

Jilles Tjoelker jilles at stack.nl
Mon Jan 14 17:47:19 UTC 2013


On Mon, Jan 14, 2013 at 11:06:07AM -0500, John Baldwin wrote:
> On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
> > With that, I think fast sigblock is too much code and complication
> > for a niche case.

> It does seem a bit complicated to me as well.

> > Most of the extra atomics in multi-threaded applications are
> > conditional on __isthreaded (or can be made so); therefore,
> > performance loss from linking in libthr should be negligible in most
> > cases.

> Sadly, this is not true.  libstdc++ turns on locking if you merely
> link against libthr, not based on testing __isthreaded.  (It does this
> by testing to see if pthread_once() works during startup, and we have
> to intentionally sabotage the pthread_once() in libc to fail for this
> to work which annoys me for an entirely different set of reasons.)

> At work we go to great lengths to avoid linking in libthr for exactly
> this reason (e.g. we have a custom port of boost that builds a
> separate set of boost libraries that are explicitly not linked against
> libthr), and we also care about exception performance (one of my
> co-workers submitted the PR about exception performance).

The code which does that check is actually under contrib/gcc. Problem
is, they designed __gthread_active_p() to distinguish threaded and
unthreaded programming environments -- it must be known in advance and
cannot be changed later. The code for the unthreaded environment then
takes advantage of this by not even allocating memory for mutexes in
some cases.

So there is no way around __gthread_active_p() returning true if libthr
is linked in. The __isthreaded check will have to be in libthr or in
contrib/gcc/gthr-posix.c and it will not do much more than avoiding
atomics.

This __gthread_active_p() thing is another barrier to bringing in a
threaded plugin in an unthreaded application. Ports people spend a fair
amount of time adding -pthread flags to things (such as perl) to work
around this.

-- 
Jilles Tjoelker


More information about the freebsd-arch mailing list