Address of data that is static, be it shared or tls or __gshared or immutable on o/s <x>

[Walter Bright via Digitalmars-d-learn]

On 9/10/2017 2:38 PM, Cecil Ward wrote:
> Ali, I have worked on operating systems' development in r+d. My definitions of 
> terms are hopefully the same as yours. If we refer to two threads, if they both 
> belong to the same process, then they share a common address space, by my 
> definition of the terms 'thread' and 'process'. I use thread to mean basically a 
> stack, plus register set, a cpu execution context, but has nothing to do with 
> virtual memory spaces or o/s ownership of resources, the one exception being a 
> tls space, which by definition is one-per-thread. A process is one or more 
> threads plus an address space and a set of all the resources owned by the 
> process according to the o/s. I'm just saying this so you know how I'm used to 
> approving this.
> 
> Tls could I suppose either be dealt with by having allocated regions within a 
> common address space that are all visible to one another. Objects inside a tls 
> could (1) be referenced by absolute virtual addresses that are meaningful to all 
> the threads in the process, but not meaningful to (threads belong to) other 
> processes. (By definition of 'process'.) or (2) be referenced most often by 
> section-offsets, relative addresses from the start of a tls section, which 
> constantly have to be made usable by having the tls base virtual address added 
> to them before they can be dereferenced adding a big runtime cost and making tls 
> very bad news. I have worked on a system like (2). But even in (2) an address of 
> a type-2 tls object can still be converted to a readily usable absolute virtual 
> address and used by any thread in the process with zero overhead. A third option 
> though could be to use processor segmentation, so tls objects have to (3a) be 
> dereferenced using a segment prefixed operation, and then it's impossible to 
> just have a single dereference operation such as star without knowing whether to 
> use the segment prefix or not. But if it is again possible to use forbidden or 
> official knowledge to convert the segmented form into a process-wide meaningful 
> straight address (as in 8086 20-bit addresses) then we could term this 3a 
> addressing. If this is not possible because vm hardware translation is in use 
> then I will term this 3b. In 3a I am going to assume that vm hardware is used 
> merely to provide relocation, address offsetting, so the use of a segmentation 
> prefix basically merely adds a per-thread fixed offset to the virtual address 
> and if you could discover that offset then you don't need to bother with the 
> segment prefix. In 3b, vm hardware maps virtual addresses to a set of per-tls 
> pages using who-knows-what mechanism, anyway something that apps cannot just 
> bypass using forbidden knowledge to generate a single process-wide virtual 
> address. This means that 3b threads are probably breaking my definition of 
> thread vs process, although they threads of one process do also have a common 
> address space and they share resources.
> 
> I don't know what d's assumptions if any are. I have very briefly looked at some 
> code generated by GDC and LDC for Linux x64. It seems to me that these are 3a 
> systems, optimised strongly enough by the compilers to remove 3a inefficiency 
> that they are nearly 1. But I must admit, I haven't looked into it properly, 
> just noted a few things in passing and haven't written any test cases as I don't 
> know d well enough yet. I haven't seen the code these compilers generate for 
> Windows.

D tries very hard to use the exact same TLS method used by the local C or C++ 
compiler, so the same assumptions and methods apply. Only of the local C or C++ 
compiler does not support TLS does D provide its own implementation.

In the case of Windows and Linux (and others), TLS support is embedded into the 
standard linker, and D makes use of that.

If an address is taken to a TLS object, any relocations and adjustments are made 
at the time the pointer is generated, not when the pointer is dereferenced. 
Hence, the pointer may be passed from thread to thread, and will still point to 
the same object. There is only ONE pointer type in D. D does not support 
multiple pointer types, such as near/far, or pointers tagged with additional 
data saying how they should be dereferenced.

TLS data is all owned by the process. TLS is not a method for inter-process 
communication.

TLS code generation for D is the same as for C and C++.