ID3D11DeviceContext is `Sync` despite the docs saying otherwise

[AlsoSylv]

Summary

In Introduction to Multi-threading in Direct3D 11 it is explicitly stated that usage of a single context across threads requires some form of external synchronization, such as a mutex. However, ID3D11DeviceContext currently implements Sync.

This is not in line with the definition of Sync which states that types that can be sent across threads and cause data-races are !Sync.

Crate manifest

[package]
name = "sync_issue_example"

[target.'cfg(windows)'.dependencies.windows]
version = "0.62"
features = [
    "Win32_Graphics_Dxgi_Common",
    "Win32_Graphics_Direct3D",
    "Win32_Graphics_Direct3D11",
]

Crate code

use windows::Win32::{
    Foundation::HMODULE,
    Graphics::{
        Direct3D::{D3D_DRIVER_TYPE_UNKNOWN, D3D_FEATURE_LEVEL_11_0},
        Direct3D11::{D3D11_CREATE_DEVICE_FLAG, D3D11_SDK_VERSION, D3D11CreateDevice},
    },
};

fn main() {
    let dxgi_factory: windows::Win32::Graphics::Dxgi::IDXGIFactory =
        unsafe { windows::Win32::Graphics::Dxgi::CreateDXGIFactory() }.unwrap();
    let dxgi_adapter = unsafe { dxgi_factory.EnumAdapters(0) }.unwrap();

    let desc = unsafe { dxgi_adapter.GetDesc() }.unwrap();
    println!("{:?}", windows::core::HSTRING::from_wide(&desc.Description));

    let mut device = None;
    let mut device_context = None;
    unsafe {
        D3D11CreateDevice(
            &dxgi_adapter,
            D3D_DRIVER_TYPE_UNKNOWN,
            HMODULE(std::ptr::null_mut()),
            D3D11_CREATE_DEVICE_FLAG(0),
            Some(&[D3D_FEATURE_LEVEL_11_0]),
            D3D11_SDK_VERSION,
            Some(&raw mut device),
            None,
            Some(&raw mut device_context),
        )
    }
    .unwrap();
    let device = device.unwrap();
    let _device_context = device_context.unwrap();

    let cloned = _device_context.clone();

    let handle  = std::thread::spawn(|| {
        // Context is now usable on two threads, which can cause deadlocks and errors.
        cloned
    });
}

[AlsoSylv]

To clarify, this allows moving the immediate context that was created to multiple threads at the same time. This behavior is only supported with a deferred context.

This is explicitly stated in the documentation here to cause data-races.

Multithreading requires some form of synchronization. For example, if multiple threads that run in an application must access a single device context ([ID3D11DeviceContext](https://learn.microsoft.com/en-us/windows/desktop/api/D3D11/nn-d3d11-id3d11devicecontext)), that application must use some synchronization mechanism, such as critical sections, to synchronize access to that device context. This is because processing of the render commands (generally done on the GPU) and generating the render commands (generally done on the CPU through object creation, data loading, state changing, data processing) often use the same resources (textures, shaders, pipeline state, and so on). Organizing the work across multiple threads requires synchronization to prevent one thread from modifying or reading data that is being modified by another thread.

[riverar]

Thanks, we'll forward this issue upstream to Win32 metadata where this needs to get investigated annotated accordingly.

cc: @MarijnS95

[AlsoSylv]

Sidenote that I should have checked last night, but this also violates the Send trait for the same reason

[MarijnS95]

Thanks for the heads-up @riverar; I wasn't the one to mark the ID3D11 types as [Agile] (and only use ID3D12, albeit that comes from the same PR) but do occasionally reference that PR such as when applying this to IDXGI.

This is however very coincidental; we were just looking at threading behaviour on VkCommandPool and as a logical consequence ID3D12CommandAllocator, which turns out not to be thread-safe either (and has further limitations, such as only allowing one ID3D12CommandList in recording mode at a given time - curious if that applies to resetting and recycling the command list as well which would have to update the ID3D12CommandAllocator structures too).

[riverar]

@MarijnS95 I was just tagging you for awareness since you're the closest person I know to this, ha! No action required!

[MarijnS95]

Understood, was just adding some extra context. We may use this opportunity to revisit some D3D12 types too.

[AlsoSylv]

A lot of the D3D12 types seem to have more complex sync needs, like ID3D12CommandList being able to be reset on any thread with ID3D12CommandAllocator passed to it, but ID3D12CommandAllocator is not safe to use by itself across threads.