Windows アプリケーションでは、バックグラウンド スレッドが GUI アイテムに直接アクセスできないことを知っています。私が完全に理解していないのは、その理由です。私が見つけた最も近い説明はこれです：
Windows フォーム コントロールへのアクセスは、本質的にスレッド セーフではありません。コントロールの状態を操作するスレッドが 2 つ以上ある場合、コントロールを強制的に矛盾した状態にすることができます。競合状態やデッドロックなど、その他のスレッド関連のバグが発生する可能性があります。コントロールへのアクセスがスレッドセーフな方法で実行されるようにすることが重要です。
これは、この MS ドキュメントからのものです。
ウィンドウ項目を一貫性のない状態にする 2 つのスレッドの特定の例について詳しく説明できる人はいますか?
Windows ウィンドウはスレッドセーフではないため、Winforms と WPF はスレッドセーフではありません。一般に、多くの状態を持つ大量のコードは決してスレッドセーフではありません。スレッドセーフにするのは非常に困難です。user32 と gdi32 に限定されません。たとえば、ブラウザもスレッドセーフではありません。Microsoft が Windows をスレッドセーフにするために途方もない努力をしたとしても、実際にはうまく機能しません。コードが自動的にスレッドセーフになるわけではないためです。ウィンドウがどのように見えるべきかを決定するためにスレッドが調整されない場合でも、グリッチと戦うことになります。解決するのが非常に難しい問題です。私にはそれを証明する傷があります。一般的な解決策は、1 つのスレッドのみがそのコンテンツを担当するようにすることです。
Windows では、kernel32 のみがスレッドセーフです。必然的にそうでなければ、スレッドを安全に使用することはできません。これは、kernel32 api 関数で確認できます。これらは、状態にほとんど影響を与えない非常に小さなことを行います。