I'm not aware of one, but it probably exists in some obscure language. I can describe how it should work though:

  * ideally, thread-local variables should not be directly exposed at all
  * variables intended to be dynamically scoped should be explicitly declared using the `dynamic` keyword at top level, using a thread-local variable (possibly of a different type) under the hood (contrary to languages that use dynamic scoping for all variables, this is opt-in, explicit, and more efficient. Note also that many languages do not have real thread-locals, they just pass the thread ID to a map, thus have atrocious performance.)
  * reading a dynamically-scoped variable just accesses the thread-local, after unwrapping the container if needed. If the top level declaration didn't have an initializer, maybe this should throw an error?
  * mutations  to the dynamically-scoped variable require an explicit keyword, and involve saving the old value as if in a block-scoped local variable, and restoring it on unwind. If there's more than one mutation in a single block this can be optimized out.
  * note that "assign a value wholesale" is only the most basic mutation; sometimes a stack is wanted (in which case the saved local value is just the depth) or a set (in which case the saved local value is the key to remove; this needs to be conditional)
  * there should be escape hatches to manually do a save, restore, or write-without-saving. These should be used only to implement nontrivial mutations in the library or to port code using unsafe thread-locals.

(an alternate approach would be to write code as if it were passing arguments to functions, but internally change them to writes to thread-local variables (only if not passed from a parameter of the same name) purely for register-pressure-optimization reasons)

When you declare a `static char *p;', how do you even know in which address of memory it is going to end up ?? How do you know what will happen if another compilation unit declares another variable of the same name? Another static library? Another dynamic library? What about initialization, what about other constructors that may read memory before main() runs? What about injected threads that are started before that? Madness, I tell you, absolute and utter madness.

The initialisation model in c++ is totally and utterly broken and indecipherable. That doesn’t stop me from doing vector<int> foo = {1,2, 3};

Avoiding thread locals due to dynamic libraries being bad is justified but still doesn't feel like the right tradeoff.

> When you declare a "static __thread char p", how do you know that for instance this is located at the 123th word of the per-thread area?

Believe it or not, it's exactly the same way it knows that "static char p" is located at the 123rd word of the data section: The linker does it!

> What if that declaration is on a dynamic library, which was loaded late (dlopen) into the process?

Same thing, except the linker is dynamic.

> What about threads which were started before that dynamic library was loaded, and therefore did not have enough space in their per-thread area for that thread-local variable, when they call into code which references it? What happens if the thread-local variable has an initializer?

Seriously? I mean, you probably do have enough space because address space is huge, but dlopen should move TLS.

> links to a 81-page document describing four TLS access models, and that's just for Unix-style ELF

Just because someone can write 81-pages about something doesn't mean that it takes 81-pages to understand something.

> Magic just means "I don't understand this"

Does this mean I don't understand that objects can have private mutable variables, or that I don't understand random() or getCurrentTime() ?

> The thread "o" is going to be the same in each expression

I don't accept the premise that I'll always be on the same thread, and if I did, I wouldn't need thread-local in the first place.

> Different people have different appetites for magic (and different definitions of what magic is).

Magic just means "I don't understand this"

And whilst I don't think it's that complicated, I also don't think you really need to understand how TLS works to use it any more than you need to understand auto mechanics to drive a car. It's faster than walking.

> I feel like thread-local takes this magic to the next level:

> assertEquals ( three(), one() + two() )

> is really:

> assertEquals ( three[thread m](), one[thread n]() + two[thread o]() )

So I think it's more like:

  assertEquals ( thread[o][three](), thread[o][one]() + thread[o][two]() )

  assertEquals ( data[three](), data[one]() + data[two]() )

- TLS is indexed off of a base address, just like data.

- The thread "o" is going to be the same in each expression, so if thread[o] can live in a special-purpose register like %fs then it won't take a general-purpose register. If data can live in a special-purpose register...

Perhaps with a better picture you too will consider TLS is basically the same as non-TLS, except it's sometimes faster because, well, special circuitry.

If anything accessing via "data" is the weird one because even though it looks like you could just set data=0, you'd find almost everyone does it indirectly via %rip, and a variable "foo" is going to be %rip(-5000) in one place and %rip(-4000) in another, but would always be %fs:-26(0) if it were TLS.