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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
