Michael Schnell schrieb:
IMO the OS provides means to allocate an thread-local memory block
(Thread Local Storage), whose content *can* be used for threadvars.
AFAI understand, in Linux (any architecture) the OS just preserves a
count of registers and the (e.g. C) compiler just uses one of them as a
pointer to the threadvars. When creating a thread the thread library
(e.g. libc) creates the threadvar block and assigns the pointer to the
said register.
Do you mean segment or general-purpose register(s)?
How is that different from WinAPI?
It's not up to the API or ABI to bother with the "record" layout of
that TLS memory block, that's all application/compiler specific.
The way how threadvars are don _is_ compiler specific. Of course it does
make sense if all compilers working for a certain OS use the same
paradigm here, so the OS _should_ provide a documentation how they
should do it,. In Linux of course the gnu C compiler team takes care of
all this.
When we consider threads created in a DLL/.so, too, then the platform
has to establish such conventions, for the entire app<->library ABI.
A threadvar simply is a member of that record, and the API specified
register contains the (direct or indirect) address of the TLS.
I suppose this is the Windows specific way....
How else should it be done, in a practical way? Registers are not a
solution, since:
Assume you have 10 units, each of which declares only one threadvar -
then you would have to reserve 10 registers for these threadvars,
application-wide!
IMO also no physical/logical separation exists, between application
(main thread) and other thread memory, everything exists in the
overall process memory. It's up to the compiler/coder, to prevent
unsynchronized access to memory locations that could be updated
concurrently by multiple threads.
Of course this is correct. But the compiler only has two options to do
this. Either do an OS API call foe each access to a global threadvar
(very slow) or dedicate a register a a pointer to the block of global
threadvars.
When we agree that threadvars (etc.) are part of the application/process
address space, then they can be accessed like any other variables - by
their unique address. In a flat memory model a strict separation would
require to shrink the application address space, by the amount required
for thread address space. IMO not very likely...
BTW, the definition of "threadvar" is not a very practical one. In
practice it should be possible to assign threadvars to *specific*
threads, otherwise *every* thread has to allocate an TLS containing
*all* the threadvars of the entire application. Furthermore it would
be sufficient to have all "threadvars" in the specific TThread-derived
classes, eliminating the need for any additional TLS.
The programmer is free to do this by using just another indirection. You
may use a single global threadvar that holds the address of an Object
(or record) that a thread allocates on the heap when it starts. The
Object or Record now can hold any thread specific information.
IMO this duplicates the OS overhead (for the thread memory (TLS)
implementation), in the application. A single threadvar then would be
sufficient for *all* threads, i.e. the one (register) provided for
thread-storage by the platform.
Many global threadvars only make sense if you start the same code in
many threads.
Can you give a more concrete example?
I'm not familiar with actual thread programming, so I have no idea about
the *usage* of threadvars in concrete code.
DoDi
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
