Multithreading guarantees? #261
-
I'd like to know the exact rules around cross-thread object usage for the library. Obviously, I assume things like separate command encoders can be used from different threads. How things work for resource management (device creation etc) is however less clear to me. I saw that the exact rules for this were "decided aren't going to solve right now" on the WebGPU spec side of things, which isn't a great start, but I guess that was also for web workers and stuff which I don't know heads or tails of. I'm a little rusty on the Rust side of things, but I assume that due to Rust's guarantees, structs like If the Rust rules can be extrapolated to the C side (being careful, obviously) then that would mean I'd just need to wrap a mutex around objects like device and call it a day. That would however be more restrictive than APIs like D3D11 or (IIRC) Vulkan, which allow concurrent access to at least the device for resource creation. Do I have these correct? Or is it more or less strict? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
It's thankfully much less strict. All types in wgpu-native are
Threading on the web is a lot more complicated, so it makes sense they punted it off of v1 |
Beta Was this translation helpful? Give feedback.
It's thankfully much less strict. All types in wgpu-native are
Send
andSync
meaning they can be freely moved across threads. Additionally, most types operate on shared references, meaning you can use the concurrently without mutexes. The only exception is CommandEncoder/RenderPass which operate on unique references, meaning you need to synchronize access across threads.webgpu-native
is, on paper, the same, but I don't know whatdawn
's situation with threading is right now.Threading on the web is a lot more complicated, so it makes sense they punted it off of v1