Cross Thread Bind And Waitable event, and Platform calls

[Dave Tapuska]

There is a common pattern amongst the graphics APIs. Creation of the GPU resources can only occur on the main thread, so the common pattern is:

WaitableEvent e;

PostCrossThreadTask(CallSomePlatformAPI, PostCrossThreadTask(e.Notify());

e.Wait();

Callees:

3d Provider

WebRTC

GPU Context

Web GPU

Web GL

Now most of the time the items accessed are cross thread ref counted objects. Like getting the shared compositor worker, or getting the established GPU sync.

Would it make sense to allow these Platform APIs to be called on whatever thread they are on, and then only enter a sync call to the main thread if we couldn't get the reference we wanted. (I know these Platform calls defer to the RenderThread, and that is only run on the main thread).

dave.

[Dave Tapuska]

Another example is the SuddenTermination on the Platform interface... (blob uses it https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/blob/blob_bytes_provider.cc;l=102;drc=0e6a1a9da0327476a5ad0a38eab88482ca3de128;bpv=1;bpt=1). We could use atomics for tracking the count, and then only post to the main thread if we want to adjust it.

[Kentaro Hara]

A shared memory programming paradigm using locks and atomics has been error-prone in Blink. Initially the original author thinks it's under control but the reality is that it becomes out of control easily. WebAudio has suffered from many stability and security bugs for years. My honest opinion is that shared memory programming should be limited to very well contained components (e.g., concurrent GC) or really performance-critical places.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHgVhZXrY4H9ENXpYXVX22FXE2FhtEc%2BVbsw62Rrsza6jM8FwQ%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Sami Kyostila]

If the shared objects are already thread-safe refcounted, then it seems fine to me to have a fast path that grabs the ref and avoids posting a task if that succeeds. We're already relying on refcounting to work safely across threads with the task posting approach.

I'm less sure of the SuddenTermination example, since it seems much easier to accidentally introduce a subtle race there.

- Sami

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jx%2BjHYJSaxWLkUmOpg_jJm9%3Dr--WQpLoWjnDtOGZMzhgw%40mail.gmail.com.

[dan...@chromium.org]

When I worked in graphics I avoided branches that sometimes posted tasks and sometimes ran code immediately. Such branches degraded my confidence in understanding what would happen at runtime and the ordering of events, and made it much harder to write unit tests.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAPuLczveKcFd0Ej1wxJ9iOAdbxDYne1FLf6R1VvbpvfmE3bAmg%40mail.gmail.com.

[Stefan Zager]

On Tue, Sep 13, 2022 at 6:29 AM <dan...@chromium.org> wrote:

When I worked in graphics I avoided branches that sometimes posted tasks and sometimes ran code immediately. Such branches degraded my confidence in understanding what would happen at runtime and the ordering of events, and made it much harder to write unit tests.

I would be interested to know how cc::SingleThreadProxy came to be. It is entirely based on violating this principle at every opportunity :)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHtyhaTW5QrqfnUEeDuaBgN0LF0O_AEzN3iJb_RrS3p_pF33fg%40mail.gmail.com.

[dan...@chromium.org]

On Tue, Sep 13, 2022 at 1:28 PM Stefan Zager <sza...@chromium.org> wrote:

On Tue, Sep 13, 2022 at 6:29 AM <dan...@chromium.org> wrote:

When I worked in graphics I avoided branches that sometimes posted tasks and sometimes ran code immediately. Such branches degraded my confidence in understanding what would happen at runtime and the ordering of events, and made it much harder to write unit tests.

I would be interested to know how cc::SingleThreadProxy came to be. It is entirely based on violating this principle at every opportunity :)

SingleThreadProxy is a different mode entirely, based on a const setting from startup, rather than a branch in a function based on where the function is run. I think that's the key distinction.