c# - C＃アプリからC ++ dllにコールバック経由でC＃アプリに戻る

Question

私はC++dllを呼び出すC＃アプリケーションを書いています。このdllは、イメージングシステムのデバイスドライバーです。画像が取得されているとき、画像のプレビューは行ごとにライブラリから利用できます。C ++ dllは、プレビューを埋めるためにコールバックを受け取ります。そのコールバックは、基本的に、最終的な画像のサイズ、現在スキャンされている行、およびデータの行自体で構成されます。

問題は、スキャンが停止してC＃コールバックが情報の取得を停止してからかなり深刻な遅延が発生することです。プログラムの流れは次のようになります。

1. C＃内からC++dllにコールバックを割り当てます
2. ユーザーがデータの取得を開始します
3. デバイスが起動します
4. dllは数秒後にコールバックの呼び出しを開始します（通常）
5. デバイスが画像形成を終了します
6. dllは、イメージ形成の2倍の時間でコールバックを呼び出しています。

この同じdllはC++アプリケーションで問題なく動作しました。その最後のステップの遅延はないようです。ただし、C＃では、コールバックをすぐに返すようにすると、遅延が発生します。コールバック内で何をしても、そこにあります。

この遅延は、アンマネージコードからマネージコードを呼び出すことの固有の制限ですか、それともこれを高速化するためにどちらかの側ができることはありますか？私はC++ライブラリライターと連絡を取っているので、C++側から修正を実装することが可能です。

編集：名前付きパイプのような単純なことを行うことはできますか？アプリケーションは独自のパイプから読み取ることができますか？

Answer 1

ガベージコレクションされたターゲットのネイティブコールバックをチェックするマネージドデバッグアシスタントが原因である可能性があります（デバッガーでデバッグモードになっていますか？）

PSAを参照してください。MikeStallによるデバッガーのブログエントリでは、Pinvokesが100倍遅くなる可能性があります。

Answer 2

相互運用レイヤー全体でファンキーなデータ マーシャリングを行っていますか? その場合、基本的にすべての画像データを変換してマーシャリングしている間に、大きな遅延が発生する可能性があります。画像データが大きいほど時間がかかるため、これを簡単にテストできます

考えられるいくつかの代替案は
次のとおりです。 1.メモリ マップド ファイルを使用しますが、単純なセマフォまたは信号システムを実装して、「データの準備ができました」および「データを消費しました」と伝える必要があります
。 2. C++ dll をコンパイルします。混合モード (C++ コードは /clr フラグを使用して .NET にコンパイルできます) では、C#/CLI
を使用します。 3. リモーティングと IPC チャネルを使用します。

それが役立つことを願っています

Answer 3

遅延は C++ 側にあることが判明しました。