[Top] [All Lists]

Re: thread-ready ABIs

To: "Tommy S. Christensen" <>, Ulrich Drepper <>
Subject: Re: thread-ready ABIs
From: Jason Gunthorpe <>
Date: Tue, 22 Jan 2002 18:12:09 -0700 (MST)
Cc: "MIPS/Linux List (SGI)" <>
In-reply-to: <>
Reply-to: Jason Gunthorpe <>
On Tue, 22 Jan 2002, Tommy S. Christensen wrote:

> Well, why not use the stack?
> I am not quite familiar with the requirements on this "thread register",
> but couldn't something like this be made to work:
>   #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET)

Last time I looked at how pthreads worked it did use the stack pointer to
decide what the TID is. It got rather ugly because the stack on thread 0
was not under program control, so it had all sorts of unknown properties.
But that could be fixed with kernel support I think.

The only reason I can think of to have a *fast* thread-local variable is
to implement thread-local storage. This is a good thing for glibc and
multi-threaded programs - the ultimate implemenation would probably be to
have gcc know about it (if ia64 has dedicated hardware, it is not
unimaginable, and other compilers do implement this)

extern int errno __attribute__((thread_local));

On i386 this has often been done using fs/gs to point to a block of ram. 

However, I expect you could probably also base the thread-local ram on the
top/bottom of the stack which means each procedure can compute the
(constant!) base in a couple of instructions. The runtime can know how
much to set aside before it begins executing the new thread. Aligning SP
can be done in a kernel independent way for tid 0. 

I don't know if this is worse than making the TLB handler slower to free
up k0/k1, it entirely depends how many functions will be using thread
local stuff.. 


<Prev in Thread] Current Thread [Next in Thread>