pub trait Access<A> { }Expand description
Type system for enforcing the lock order on Hub fields.
If type A implements Access<B>, that means we are allowed to
proceed with locking resource B after we lock A.
The implementations of Access basically describe the edges in an
acyclic directed graph of lock transitions. As long as it doesn’t have
cycles, any number of threads can acquire locks along paths through
the graph without deadlock. That is, if you look at each thread’s
lock acquisitions as steps along a path in the graph, then because
there are no cycles in the graph, there must always be some thread
that is able to acquire its next lock, or that is about to release
a lock. (Assume that no thread just sits on its locks forever.)
Locks must be acquired in the following order:
AdapterDeviceCommandBufferRenderBundlePipelineLayoutBindGroupLayoutBindGroupComputePipelineRenderPipelineShaderModuleBufferStagingBufferTextureTextureViewSamplerQuerySet
That is, you may only acquire a new lock on a Hub field if it
appears in the list after all the other fields you’re already
holding locks for. When you are holding no locks, you can start
anywhere.
It’s fine to add more Access implementations as needed, as long
as you do not introduce a cycle. In other words, as long as there
is some ordering you can put the resource types in that respects
the extant Access implementations, that’s fine.
See the documentation for Hub for more details.