Thread Safety

[kainino0x]

This thread is for figuring out what operations are thread-safe (internally synchronized). Last weeek's webgpu.h meeting ended up discussing this as an offshoot of #9 because of the question of whether device.destroy() must be externally synchronized with encoding (i.e. a multithreaded application must add its own locks).

wgpu in safe Rust wouldn't allow this kind of unsafety, so it's more of a question of whether dawn and wgpu-core would have (unsafe) encoder methods that require external synchronization, perhaps alongside safe versions. In the safe version, each individual encoder command has to take a read-lock on the device's read-write-lock, or we would need something else clever, like a way for the entire encoder to take a lock until it's finished or dropped, without making it impossible to ever actually destroy a device.

I think we agreed to just go ahead with making these internally synchronized. Maybe in the future if we can't come up with something better and consider adding unsafe versions of encoder commands?

[austinEng]

Had an idea to help with some of the encoding overhead I was worried about.

To reiterate, making device.destroy() internally synchronized means that if it actually does cause resources to be destroyed, every usage of the API needs to take a read-lock on the device's read-write-lock so that actual destruction doesn't race with some other thread using the device.

Read-locks are unfortunate because internally they're bumping a counter of the number of readers. If you touch this counter from many threads, you invalidate the cache a lot and have a lot of write contention. Maybe your standard library implementation is clever to help avoid it.

The overhead of the read-lock would be unfortunate for encoding operations, but one way to alleviate it would be to have the read-lock last as long as the encoder does. That way, device destruction doesn't happen until the encoder's last reference is dropped.
Note: to avoid deadlock, you'd probably do something more like bump a device-is-used counter, and when it hits zero, that thread is the thread that performs the device destroy if the destroyed bit is also set.

[kainino0x]

A few cases I think we had conclusions on but I didn't write down:

• two encoding calls on the same encoder. I think these can be thread unsafe. Rust would prevent this by ownership.
• two CreateView calls. Implicitly I think we made this safe. I think it should be, because this isn't too hot, and it's a reasonable expectation.

[kainino0x]

No code change for this, so closing but keeping the needs docs label.