RE: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches(1/3)

[Philip Blundell <pb at nexus dot co dot uk>]

I was thinking that the kernel would select a location for the variable
within the user's address space, probably at the top of the initial
stack (say 0xbffffffc), and communicate that to the application through
the elf auxiliary vector.  Or we could just pick an address and define
that as part of the ABI, though that seems a bit ugly.

Your suggestion of __thread_self[cpu_num] does seem like an attractively
simple method, except that I can't think of any good way for the thread
to know which cpu it's currently executing on.  Given that a context
switch might result in it flipping onto another cpu at any time, I think
you'd always have a race between obtaining the cpu number and loading
the value from the __thread_self array.

p.

On Fri, 2003-06-13 at 04:36, Hu, Boris wrote:
> THREAD_SELF() is heavily used in nptl, such as pthread_create(), 
> pthread_exit(), pthread_join(), etc.  
> 
> I have forword several related discussion mails to linux-arm-kernel but no 
> responsed. :( 
> 
> About SMP issue, first, I wonder if it needs to support so far, for there is 
> no SMP ARM so far. Secondly, even when SMP ARM appears in the future, 
> it is easy to extend the current solution -- change __thread_self to
> __thread_self[cpu_num]. Do I miss sth? 
> 
> I have a question about letting kernel choose the location of the thread 
> variable rather than the application. The benefit of the way is the kernel 
> could improve the variable access performance by dcache lockdown. 
> But how does the user space program to access the thread variable in 
> the kernel space? system call?
> 
> boris