Do we need more for TLS?

[abrown]

In the TLS section, the overview claims that we can use a toolchain-generated TID to determine the TLS region in linear memory — this has a chicken and egg problem. If the toolchain generates a TID (or even if one is passed in to the thread start function), we either (a) need to thread that value through to all its uses as an extra function parameter or (b) need to find some thread-local place to put the value to use it later (e.g., a TID-indexed region in memory). The problem with (a) is that it is onerous for toolchains; please comment if you do not think so. But (b) is impossible: when we need to access TLS later to retrieve the TID, we don't have the TID available to find it. Thanks to @alexcrichton for pointing out this problem!

What to do? As we discussed this, several solutions came to mind:

• a new thread.id instruction (or import, depending on this discussion
• a new mechanism for allowing a global to be thread-local;
  • e.g., a new thread-local attribute one could add to a global (e.g., (thread-local global $g (mut i32) (...)) or (global $g (thread-local mut i32) (...)))
  • or even a completely new module object (e.g., (thread_local $g i32 (...)))

The result of this discussion should help us fix the TLS section as well as indicate in the TID section how one can access the TID values during execution.

[conrad-watt]

With @syg's scheme here (#4 (reply in thread)) we'd already need to thread the JS context through each function as an argument, so also making this the mechanism by which TIDs are propagated might be viable.

@lukewagner and I also discussed a thread.id instruction a while ago, and I think it makes sense in a world where we have thread.spawn. Assuming we allow "arbitrary arguments" to thread.spawn, it may make sense to require that the first argument be an i32 which sets the thread ID.

[alexcrichton]

One perhaps important consideration for this is that the linear-memory shadow-stack pointer, currently stored in a global today, will need to become thread-local and can be performance sensitive as well. A thread.id instruction may not be appropriate for this performance-wise because modules would have to perform a form of reverse-lookup from thread ID to thread-specific-data in memory which may not be a simple offset operation.

Mostly I wanted to say that while thread.id may be sufficient from a functionality point of view it may not be sufficient from a performance point of view.

[conrad-watt]

I think it might be hard to make more general TLS fast on the Web as well. Because Wasm modules on the Web are compiled to be parameterised over different instantiations, any thread-local global variable would need to be indexed both by the current instance and by the current thread/Web worker. I don't have a clear mental model of how this can be made fast, especially since both dimensions (instance and thread) can grow dynamically (edit: and especially if Wasm threads aren't mapped 1-to-1 to OS threads).

One way to make the thread.id scheme faster would be for the compilation scheme to Wasm to directly assign the address of the thread-local-storage allocation in linear memory as the thread ID, instead of making the thread ID an index into a table of addresses. This could at least eliminate one indirection.

(EDIT: separately, it might be worth asking how efficiently the thread-local allocation address could be propagated as a function argument, in the spirit of the sketch above).

[alexcrichton]

To restate to make sure I understand, it sounds like when combining the above sketch there could be a scheme such as:

• The id of a thread is wasm-defined and is required as an argument to thread spawning
• The id of a thread can be acquired at any time via a thread.id instruction which returns whatever the thread was spawned with

Thus by using a linear memory address as the id then that solves the performance issue since there's a quick/easy way to get your address and then everything else is indirected from there (e.g. the stack pointer, custom thread locals, etc)

That sounds reasonable to me and I agree would work (and is naturally much easier than adding a whole thread local global type or something like that)

[conrad-watt]

Yes, that's the idea I'm getting at (which has not survived contact with the real world yet!)

If, due to concerns from the Web side, we have to part out thread.spawn/id to a separate post-proposal, I could also imagine identical functionality being provided by host imports (which would then be virtualisable with thread.spawn/id once these instructions are standardised).

[yamt]

how this can be made fast, especially since both dimensions (instance and thread) can grow dynamically (edit: and especially if Wasm threads aren't mapped 1-to-1 to OS threads).

i guess it depends on how fast you want to make it.
if pthread_set_specific etc is considered fast enough, it isn't too difficult.

[yamt]

If, due to concerns from the Web side, we have to part out thread.spawn/id to a separate post-proposal, I could also imagine identical functionality being provided by host imports (which would then be virtualisable with thread.spawn/id once these instructions are standardised).

isn't it supposed to be used to replace eg. stack pointer?
using a host call to obtain stack pointer sounds like a performance disaster.

[sbc100]

Aren't all globals already thread-local unless explicitly marked as "shared" using the new "shared" attribute described in https://github.com/abrown/thread-spawn/blob/main/proposals/thread-spawn/Overview.md#shared-attributes? I assume I'm missing something here.

[yamt]

esp. since thread creation and instance creation may arbitrarily interleave

well, how can it happen?
thread creation is done with thread.spawn instruction or whatever.
it means the instance has already been created, doesn't it?
or, maybe i'm missing something obvious about web-based engines?

[conrad-watt]

If the thread calls back into JS (through something like this) the JS can call instantiate again. Also, other threads can call instantiate. In both cases, function instances created beforehand may be imported by the new module instances (and then those new module instances can create additional Wasm or JS threads which have function instances postMessaged to them or transmitted through shared tables, and so on).

Essentially, in general every thread, whether created in Wasm or JS, needs to be able to handle the TLS of every Wasm instance (whether created before or after the thread, and whether currently "in-scope" or not).

[yamt]

ok. it sounds far more dynamic than engines i'm familiar with.

i guess a simple solution is to require a thread itself to allocate/initialize the tls explicitly.
for example,

• introduce thread-local global type
• global.thread.init instruction prepares the global for the calling thread.
• if global.get/global.set is called before global.thread.init, trap.

[conrad-watt]

Ah, that's a very interesting idea. Maybe it could be a validation-time check like our current non-nullable locals - this would save an "is initialised" check on each regular global access. A validation-time initialisation check would have to be separately performed in each function, but if the global.thread.init operation was idempotent then I think something like this could work!

[yamt]

what's "our current non-nullable locals"?

i expect global.thread.init can fail on runtime as it can involve resource allocations.
i expect it to be done as a part of eg. a thread startup routine for pthread_create.

[yamt]

maybe the minimum approach is to have a convention to reserve a few parameters for all shared functions.
eg. the first parameter is always a stack pointer, the next parameter is always a tls pointer, etc.
this approach doesn't need any wasm-level primitives like thread-local global or thread.id.

a C compiler, or whatever entity which generates shared functions, can insert these "thread context" parameters automatically.

how do you think?

[alexcrichton]

One downside of this is that embedders invoking wasm (e.g. JS invoking a function) has to figure out what values to pass in. The module could perhaps export globals or something like that for "get the initial stack pointer" or TLS pointer or such, but that's, in my opinion at least, a pretty onerous thing to do compared to what happens today where it's all an internal implementation detail.

Put another way, while functionally I think that this would work, I personally feel that practically this exposes too many implementation details to embedders/callers,

[yamt]

do you mean to use a shared function as an entry point?
i suspect it isn't straightforward anyway because the stack or such for the calling thread somehow needs to be allocated and associated to the thread.
to me it isn't obvious how it looks like even with other approaches.

[alexcrichton]

Yeah a lot of details are still not clear to me at least so can't say much concrete, but yes I'm imagining what needs to happen if JS calls a shared function. If the first parameter is the stack pointer, for example, I'm not sure how JS would learn what the stack pointer is.

For spawning a new thread internally from within that module that seems doable because the function used to start the module could somehow close over a stack pointer allocated during thread creation. The entry point could be a special toolchain-specific function in that scenario.