[fpc-devel] OO rewrite - technical questions

[Hans-Peter Diettrich]

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