[fpc-devel] OO rewrite - technical questions

Michael Schnell mschnell at lumino.de
Tue Jul 20 11:13:57 CEST 2010


  On 07/19/2010 05:16 PM, Daniƫl Mantione wrote:
>
> You could also work with the current thread id as a key to a pointer 
> to the threadvars. 
Theoretically you can, but in praxis this is not doable for each access 
to a threadvar, as you would need to request the thread ID from the OS 
with each access to the threadvar which would be horribly slow. You 
can't store the thread ID in a global variable nor on the heap (as those 
obviously are not a threadvars) so you can store it on the stack or in  
register, which both are dedicated to each thread. As the stackpointer 
value is not known at runtime within any function, using the stack is 
not possible.So AFAI can see, without alternate OS-support, dedicating a 
register as a pointer to the threadvars, is the only viable option a 
compiler has.

AFAIK, in Linux the archs specs define which register is supposed to be 
used as a theradvar pointer by compilers. There might be some archs that 
don't define a register but a dedicated memory location, managed by the 
OS when scheduling threads and processes, to be the threadvar pointer.

> However, segment registers are indeed the way libpthread resolves the 
> TLS keys.
Obviously.

> Yes, though I am still puzzled how it works on x86_64; it seems 
> regvars there are also accessed using fs, but x86_64 prevents you from 
> writing to segment registers.
>
In fact it is not critical that the threadvar register (with X86/32 
Linux) is a segment register, With NIOS it's just one of it's 32 general 
purpose registers. (I'm not very deep into ARM yet, but I'm quite sure 
that its similar here). So it might be the same with X86/64. The 
compiler just needs to make sure that this register is not modified ever 
and that it's used as a threadvar pointer.

-Michael



More information about the fpc-devel mailing list