You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The deadlock instrumentation in #5539 suggests that wgpu-core could deadlock if five threads happen to be doing exactly the wrong thing. Specifically, while running the boids example tests, there is some point at which a thread holds each lock in this list, while trying to acquire the next:
CommandBuffer::data
Buffer::map_state
Device::pending_writes
Device::life_tracker
Device::temp_suspected
CommandBuffer::data
Since CommandBuffer::data appears at both the start and the end of the list, that means that if five threads happened to be holding each of these locks while trying to acquire the following one simultaneously (six list entries; five threads to bridge each step), then wgpu-core would deadlock.
I've not observed this deadlock in practice, and given the level of coincidence required it seems unlikely to be high-impact.
The text was updated successfully, but these errors were encountered:
The deadlock instrumentation in #5539 suggests that wgpu-core could deadlock if five threads happen to be doing exactly the wrong thing. Specifically, while running the
boids
example tests, there is some point at which a thread holds each lock in this list, while trying to acquire the next:CommandBuffer::data
Buffer::map_state
Device::pending_writes
Device::life_tracker
Device::temp_suspected
CommandBuffer::data
Since
CommandBuffer::data
appears at both the start and the end of the list, that means that if five threads happened to be holding each of these locks while trying to acquire the following one simultaneously (six list entries; five threads to bridge each step), thenwgpu-core
would deadlock.I've not observed this deadlock in practice, and given the level of coincidence required it seems unlikely to be high-impact.
The text was updated successfully, but these errors were encountered: