This is an archive of the discontinued LLVM Phabricator instance.

[lld][WebAssembly] Relax limitations on multithreaded instantiation
ClosedPublic

Authored by tlively on Sep 13 2021, 1:58 PM.

Details

Summary

For multithreaded modules (i.e. modules with a shared memory), lld injects a
synthetic Wasm start function that is automatically called during instantiation
to initialize memory from passive data segments. Even though the module will be
instantiated separately on each thread, memory initialization should happen only
once. Furthermore, memory initialization should be finished by the time each
thread finishes instantiation. Since multiple threads may be instantiating their
modules at the same time, the synthetic function must synchronize them.

The current synchronization tries to atomically increment a flag from 0 to 1 in
memory then enters one of two cases. First, if the increment was successful, the
current thread is responsible for initializing memory. It does so, increments
the flag to 2 to signify that memory has been initialized, then notifies all
threads waiting on the flag. Otherwise, the thread atomically waits on the flag
with an expected value of 1 until memory has been initialized. Either the
initializer thread finishes initializing memory (i.e. sets the flag to 2) first
and the waiter threads do not end up blocking, or the waiter threads succesfully
start waiting before memory is initialized so they will be woken by the
initializer thread once it has finished.

One complication with this scheme is that there are various contexts on the Web,
most notably on the main browser thread, that cannot successfully execute a
wait. Executing a wait in these contexts causes a trap, and in this case would
cause instantiation to fail. The embedder must therefore ensure that these
contexts win the race and become responsible for initializing memory, since that
is the only code path that does not execute a wait.

Unfortunately, since only one thread can win the race and initialize memory,
this scheme makes it impossible to have multiple threads in contexts that cannot
wait. For example, it is not currently possible to instantiate the module on
both the main browser thread as well as in an AudioWorklet. To loosen this
restriction, this commit inserts an extra check so that the wait will not be
executed at all when memory has already been initialized, i.e. when the flag
value is 2. After this change, the module can be instantiated on threads in
non-waiting contexts as long as the embedder can guarantee either that the
thread will win the race and initialize memory (as before) or that memory has
already been initialized when instantiation begins. Threads in contexts that can
wait can continue racing to initialize memory.

Fixes (or at least improves) PR51702.

Diff Detail

Event Timeline

tlively created this revision.Sep 13 2021, 1:58 PM
tlively requested review of this revision.Sep 13 2021, 1:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 13 2021, 1:58 PM
dschuff accepted this revision.Sep 13 2021, 2:44 PM

I think this makes sense as a simple tweak to our current protocol. I could imagine us wanting to rethink it more generally in the future, but I don't think that needs to block the worklet fix.
Maybe also reference the bug number in the commit message?

This revision is now accepted and ready to land.Sep 13 2021, 2:44 PM
tlively edited the summary of this revision. (Show Details)Sep 13 2021, 2:58 PM
sbc100 added inline comments.Sep 13 2021, 3:34 PM
lld/test/wasm/data-segments.ll
125

We should probably convert these tests to use objdump -d now that its working!

tlively added inline comments.Sep 13 2021, 4:03 PM
lld/test/wasm/data-segments.ll
125

Good idea! I'll take a look at that.