Re: RFC: Implement __libc_single_threaded support

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 04/02/2019 18:54, Florian Weimer wrote:
> * Rich Felker:
> 
>> So all your optimization is doing is saving one level of indirection
>> for access from shared libraries. It does not save any expensive setup
>> for PC-relative access on archs where it's expensive.
> 
> That's correct.  I'd like to hear the point of view of architecture
> maintainers on this matter.
> 

exposing a __libc_single_threaded api sounds useful to me.

doing the libc_nonshared.a trick that makes it local so an
indirection can be saved, but requires updates to all dsos
on thread creation/exit, sounds like a hairy abi to expose,
but such optimization is certainly ok inside glibc (as i
understand libc.so and libpthread.so can already access
this info locally now, which we don't want to regress)

(on some targets tp-relative access may be even faster than
pc-relative access, so if we want this super optimized then
we could put it at a fixed magic tls offset and then there
is no need for O(n) operation to update it.. but a magic tls
offset abi is even worse so i think i prefer to just use a
normal extern object symbol in libc.so)

> I can prepare a patch using just one variable if someone wants to run
> actual performance measurements.  Other aspects of the complexity will
> remain, though.  I don't think the thread counter should be read
> directly, but rather an infrequently updated variable, as in the current
> patch.  Registration would go away, but the complicated rules for
> updates of the single-threaded indicator in statically linked processes
> which use dlopen would remain.  However, dlmopen support would come
> naturally as long as we put the variable into the (globally shared)
> dynamic loader.
> 
> Thanks,
> Florian
>