For WebNN graph asynchronous execution, the main thread and the worker thread may access the input or output array buffers at the same time that would cause the race condition issue.

This issue was captured during the Chromium CL review. Thanks @wacky6 for pointing it out. There are some steps may cause this issue:

1. Main thread calls MLContext.compute() with input and output array buffers.
2. The input and output array buffers are passed to worker thread for execution.
3. Main thread may change the array buffers concurrently, e.g., trigger reallocation, detaches the array buffers or modify the content after the validation
4. The worker thread may read / write to the wrong backing stores.

The root cause is, in the current design, both the main thread and worker thread can access the input and output array buffers at the same time.

A possible solution could be similar to ReadableStreamBYOBReader interface. It transfers the user-supplied array buffers to a new ones and post the new ones to the worker thread for execution. The new array buffers would share the same backing store of the user-supplied ones, so there are no extra memory copies. But the main thread is not able to change them during the execution, because they are already detached. After worker thread fills the results, the promise will be resolved with the new array buffers. So the main thread can access the results after that. There are more details of this design in @domenic 's post.

This may require a change to WebNN MLContext.compute() method to something like:

dictionary ComputeResult {
  MLNamedArrayBufferViews inputs;
  MLNamedArrayBufferViews outputs;
};

partial interface MLContext {
  Promise<ComputeResult> compute(
      MLGraph graph, MLNamedArrayBufferViews inputs, MLNamedArrayBufferViews outputs);
};