thread-local data access
Jakub Jelinek
jakub@redhat.com
Wed Sep 27 00:41:00 GMT 2000
On Tue, Sep 26, 2000 at 10:26:14PM -0700, Ulrich Drepper wrote:
> We slowly have to think about the platforms which do not yet have
> thread-local data access through anything but the POSIX API. This
> will be a problem since there are at least two changes coming up which
> require fast access the thread-local data.
>
> The situation from my perspective is as follows:
>
> - x86: %gs register, fast enough
> - SPARC: dedicated thread register
> - IA-64: likewise
> - Alpha: PAL call, fast enough (according to rth)
>
> What about the other architectures? I guess m68k is not really that
> important anymore. More of a problem for me are Arm, MIPS, and PPC.
> Also, do the people who designed the ABI for PA, SH, and S390 thought
> about this?
Thinking about it, wouldn't be better to just make the other arches slower
(e.g. by managing a global array of pointers to thread-local data indexed by
say [STACK_POINTER >> 16] (provided that we make sure that no two thread
stacks share the same 64K page))?
I know two memory accesses (and perhaps some cache misses) plus some math
will slow things down, on the other side I think it would be far worse if
programs won't be portable accross the architectures.
A threaded program could mmap (...PROT_NONE...) the 64K*sizeof(void *) array first
and then as the various stacks are created/destroyed, they would be
mmaped/munmaped as needed and filled with thread local pointers.
Jakub
More information about the Libc-hacker
mailing list