[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Mar 2014 19:04:05 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Transition path for removing lazy init of thread pointer
On Mon, Mar 24, 2014 at 01:49:15PM -0400, Rich Felker wrote:
> Phase 1: Initialize the thread pointer at startup, but do not make
> anything in musl assume that the thread pointer is valid unless the
> [...]
Phase 1 is now complete. The intent is that it not break any usage
(even on ancient kernels that are unsupported) that was not already
broken before, so regression reports would be very appreciated if I'm
wrong about that.
At this point we now have two mandatory syscalls at startup on most
archs (just one where setting the thread pointer is entirely a
userspace operation). The second syscall is set_tid_address, and it
seems like it should only be needed it pthread_create is being used
(to that pthread_join will work), but it serves a second purpose of
standing in for gettid() too. We could, however, eliminate it in some
cases:x
- In static-linked programs that never need to know their own tid and
never create threads, it can be skipped. This could be achieved with
some weak symbol magic.
- Even in dynamic-linked programs, we could defer the tid lookup until
it's needed by adding a __gettid() function/macro that looks in the
thread structure, and if it finds zero, calls set_tid_address. This
might add a few cycles to some synchronization primitives, but we're
shaving a good number of cycles now anyway since lazy thread-pointer
initialization is gone and we can inline the thread-pointer access
in a lot more places.
I'd welcome feedback on whether these sorts of optimizations (well,
more like tradeoffs than outright optimizations) are desirable.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
