This is the mail archive of the
mailing list for the glibc project.
Re: RFC: Implement __libc_single_threaded support
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.