[fpc-devel] OO rewrite - technical questions
DrDiettrich1 at aol.com
Fri Jul 23 14:06:50 CEST 2010
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
Assume you have 10 units, each of which declares only one threadvar -
then you would have to reserve 10 registers for these threadvars,
>> 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
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.
More information about the fpc-devel