ブースト asio 非同期呼び出しを使用する Windows C++ DLL と通信するクライアントを C# で作成しています。管理された環境では ASIO がうまく機能しないことを以前に読みました。VC++ DLL は、I/O ハンドラー用のアンマネージ スレッドを作成するアンマネージ プロジェクトです。C# コードは、pinvoke を介して C++ DLL へのメッセージの送信を処理するバックグラウンド スレッドを作成します。私の質問は、boost::asio::async_write メソッドの呼び出しをマネージド スレッドで実行できるかということです。または、アンマネージ スレッド上にある必要がありますか?
マネージド スレッドで async_write を呼び出すことができれば、ロジックと処理を簡素化するのに役立ちます。しかし、.NET ガベージ コレクタが実行されてスレッドが停止するとどうなるかが心配です。ASIOがそれを処理できるかどうかはわかりません。C# コードで定義されたデータへのポインタを渡していないので、問題にはなりません。
「マネージド スレッド」の概念は弱いものであり、オペレーティング システムは 1 種類のスレッドしかサポートしていません。マネージド コードを実行するスレッドは特別なものではありません。マネージド コードは、C コンパイラが生成するのとまったく同じ種類のマシン コードに変換されます。唯一の違いは、CLR がスレッドを認識しており、ガベージ コレクションが発生したときにスレッドのスタックを確認する理由があることです。オブジェクト参照を含む可能性のあるマネージ コードのスタック フレームを見つけるために必要です。
ネイティブ コードに属するスタック フレームには関心がなく、単純に無視されます。はい、GC が検索を実行している間、スレッドが一時停止することがありますが、それは現在マネージ コードを実行している場合のみです。ネイティブ コードは実行を続けます。GC が進行中の場合は、マネージ メソッドに戻ったときにのみブロックされます。この一時停止は、それ以外の点では、スレッドが一時停止する可能性がある他の種類の理由と変わりません。たとえば、オペレーティング システムのスケジューラが他の何かを実行しているときにプロセッサがしばらく失われるなどです。
したがって、boost::asio を使用しても問題ありません。何も問題はありません。オペレーティング システムの呼び出しなど、マネージ プログラムがネイティブ コードを実行できる他の多くの方法と同様です。細心の注意を払う必要があるのは、コードが /clr を有効にせずにコンパイルされるようにすることだけです。ブースト コードを IL にコンパイルするとうまくいきますが、あまり効率的ではありません。