問題タブ [io-completion-ports]

Windows 2008のデフォルトのselectリアクターに問題があります。Windowsの理想的なソリューションのように見える代替リアクター、iocpreactorがあります。ドキュメントには実験的なものとしてリストされており、「ほぼ準備ができています」。

これは実際にはどういう意味ですか？これまでのところ、問題なくテストしてきました。一般的に使用されていますか？他の誰かがそれをお勧めできますか？

IOCompletionPortを使用してクライアントから読み取るサーバーを実装しようとしています。私はこの例に非常に似たものを持っています。

私が正しく理解していれば、これは私のデザインであるはずです：

1. [メインスレッド]リッスンソケットを作成し、バインドしてリッスンします
2. [メインスレッド]イベントを作成し、WSAEventSelectを使用してソケット受け入れ信号にアタッチします
3. [スレッドを受け入れる]イベントを待ち、クライアントを受け入れる
4. [スレッドを受け入れる]クライアントが接続するとき、CreateIOCompletionPortを使用してIOCompletionキューを使用します
5. [Accept Thread] Acceptスレッドは、オーバーラップパラメータを使用して最初のWSARecvを呼び出します
6. [ワーカースレッド]キューを使用して、WSARecvにリーダーフォロワーパターンを実装します

WSARecv（ここ）を読んだ後、データの準備ができていれば、WSARecvがデータ​​とともにすぐに戻る可能性があることを発見しました。これは、クライアントが十分な速度で送信した場合、ワーカーがIOキューに戻らずにWSARecvでループする可能性があることを意味するため、ちょっと奇妙に思えます-そしてそれはクライアントの飢餓を引き起こす可能性があります...

ここに私の質問は次のとおりです。

1. WSARecvをすぐに戻らないように「強制」する方法はありますか？つまり、100％の確率でIO_PENDINGを返すのですか？
2. そうでない場合-スケーラビリティのために最適化された正しい設​​計は何でしょうか？

これが私がWSARecvを使用する方法です：

olStructは、OVERLAPPED構造体の拡張機能です。

編集：PostQueuedCompletionStatusを使用してWSARecvから取得したものを再投稿することになりました。 回答を参照してくださいが、他の解決策を聞きたいです

私は、大量のデータをディスクに書き込み、後ではるかに少量のデータを読み戻す必要があるプログラムを開発しています。関連するデータをまとめて「ビン化」する必要があり、それをどう処理するかを理解したら、データをさらに処理できます。基本的にはデータベースのように機能しますが、ディスク上に一時ファイルがあります。一時ファイルの一部は、ディスク上のデータを読み戻した後は気にしないため、かなり頻繁に再利用されるため、ファイルのその部分を再利用できます。シーケンシャル I/O は単に遅すぎるため、I/O 完了ポートを使用してこれを実装しています。

問題は、データを読み取ったときに、すべてが返されないことがあることです。たとえば、読み取りバッファーをゼロに設定し、たとえば 20 バイトの読み取り操作を実行します。対応する完了イベントがトリガーされると、読み取りバッファーの一部またはすべてがディスク上にあるはずのものと一致しませんが、すべては一致しません。ゼロにはなりません。時折、これを検出して 5 秒間スリープさせ、同じ部分をもう一度読んでみると、最初に読んだものと一致することがあります。これは最上位の SSD で行われているため、ディスクにフラッシュするには 5 秒で十分です。ただし、アプリケーションを停止してファイルの内容を確認すると、ディスク上では正しくなっています。以前の書き込みがディスクにフラッシュされておらず、古いデータを読み取ろうとしたかのようです。

その理論をテストするために、セクション全体を読みながら 0xFF を書き込んでみました。このエラーが再び発生したとき、私の読み取りバッファには予想どおり 0xFF が含まれていませんでした。おそらく、私は古いデータを読んでいません。

また、完了イベントから返されたバイト数が ReadFile に渡したバイト数と一致していることも確認しましたが、一致しています。完了イベントまたは ReadFile (ERROR_IO_PENDING 以外) によって返されるエラーはありません。FILE_ATTRIBUTE_NORMAL、FILE_FLAG_OVERLAPPED、および FILE_FLAG_RANDOM_ACCESS を使用して一時ファイルを作成しています。

また、読み取りを試みる前に、ファイルの特定の部分に対するすべての保留中の書き込みが完了するのを待ってみましたが、役に立ちませんでした。Windows がそれをしてくれることを願っていますが、私が読んだどのドキュメントにも記載されていません。

部分的または破損した読み取りのように見える理由について、私は本当に途方に暮れています。私は全力を尽くしているので、この動作を引き起こす可能性のあるアイデアを本当に探しています。

問題

C# を使用して非常に大きなデータ構造を保存および読み取ることができる必要があります。構造自体はかなり単純です。これは、一定サイズの単純な構造体の非常に長い配列です。

わかりやすくするための例:

これらを可能な限り高速かつ効率的にファイルに保存およびロードできるようにしたいと考えています。

一般的な方向性

これまでの私の考えは、データをセグメントに分割し、概念的にはもちろん、それらのセグメントをタスクに割り当て、非同期でファイルに書き込むことです。FileStream.WriteAsync はこれに最適なようです。

私の問題は読み取りに関するものです。FileStream.ReadAsync API から、実際にはプリミティブの途中で、結果が各構造の途中でカットされる可能性があることは完全に合理的です。もちろん、これを回避することはできますが、何が最善の方法なのか、OS のバッファリング メカニズムにどの程度干渉するのかはわかりません。

最終的には、各バッファから MemoryStream を作成し、MemoryStream.MemoryStream(byte[])それぞれをバイナリ リーダーで構造体に読み込む予定です。

質問

では、これを解決する最善の方法は何でしょうか? 私の方向は良いですか？より良い解決策はありますか？コード例とリンクをいただければ幸いです...

結論

パフォーマンス テストを行った後、BinaryReader でファイルを読み取るか、FileStream.ReadAsync で複数のリーダーを使用すると、ほぼ同じパフォーマンスが得られることがわかりました。

スー……その質問は無意味です。

RegisterWaitForSingleObjectI/O 完了ポートを使用することと、I/O が完了するまでスレッド プールのスレッドを待機させるために使用することの違いは何ですか?

そのうちの 1 つは高速ですか? もしそうなら、その理由は?

フレームワークで一般的なスレッド割り込みメカニズムとしてユーザー アラートを使用するため、fAlertable を TRUE に設定してこの関数を使用しています。この関数に関する MSDN ページのコメントによると、

呼び出しがアラート可能な待機状態に入り、ユーザー APC が GetQueuedCompletionStatusEx の戻り値を TRUE にディスパッチできる場合、ulEntriesRemoved はゼロではなく、OVERLAPPED_ENTRY の「パック」は変更されません。したがって、API を呼び出す前に、すべての OVERLAPPED_ENTRY の lpOverlapped メンバーに既知の一意の値が設定されていることを確認すると、削除されたエントリが APC であるか I/O 完了パケットであるかをより簡単に検出できます。価値。

最初のエントリだけでなく、すべての OVERLAPPED_ENTRY をチェックする必要があるのはなぜですか? GetQueuedCompletionStatusEx() は常に出力配列を順番に埋めるのではないので、配列全体 (または少なくとも ulEntriesRemoved まで) をループするのではなく、最初のものだけをチェックする必要がありますか? さらに、この関数が複数の完了ポート エントリを同時にデキューすることを考えると、アラートと 1 つ以上の完了エントリの両方を決して返さないことが保証されますか? アラート中に ulEntriesRemoved がゼロ以外になるというコメントのメモを考えると、この可能性について特に心配しています。このページのコメントには、「キューに I/O 完了パケットがある場合、ユーザー APC はディスパッチされません」と記載されていますが、

システムが、スレッドに対するユーザー アラートと完了ポート エントリの両方を組み合わせてキューに入れ、スレッドが GetQueuedCompletionStatusEx() を実行するとします。ドキュメントから、関数がこの呼び出しですべての完了エントリをデキューし、その後の各呼び出しごとに 1 つのユーザー アラートをデキューするかどうかはわかりません (これ以上完了エントリがキューに入れられていないと仮定します)。ドキュメントを考えると、それが最も可能性の高いケースのように思われますが、間違っていると判明する可能性のある仮定をしたくありません...

私は、Windows HTTP Server API に関連する Windows プログラミングの IO Completion ポートのドキュメントを調べていました。

したがって、HTTP サーバー API には、応答/要求を抽象化したキューがあります。関連情報を取得するためのキューへのハンドルがあります。

IO Completion ポートをこれに関連付ける場合、キューをハンドルとして使用する必要があるということですか? これは粒度を低下させませんか？完全なキューではなく、各要求に IO Completion ポートを関連付けることはできませんか?

詳細なクエリ: Windows http サーバー API の要求キューを使用して、特定の URL を登録します。そのため、キューに多くのリクエストがある可能性があります。キュー自体ではなく、各要求/応答に IO Completion ポートを関連付けるにはどうすればよいですか。

IO 完了: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363862(v=vs.85).aspx

キューのドキュメント: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364483(v=vs.85).aspx

リクエストを受け取る: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364495(v=vs.85).aspx

アプリケーションが外部サービスに依存している場合に非同期プログラミングを使用することが重要である理由の 1 つは、ASP.NET が IO 完了ポートを使用できるようにすることです。これにより、外部サービスの応答を待っているスレッドをブロックするのではなく、ASP.NET外部サービスが応答するたびに、IO 完了ポートで実行を保留し、別の要求に対応するためにスレッドを使用できます。その後、ASP.NET はその実行を再度取得して再開します。このように、どのスレッドもブロックされません。

非同期メソッドの例は次のとおりです。

しかし、外部サービスへの複数のリクエストを使用するとどうなるでしょうか? ASP.NET はそれをどのように処理しますか?

まだ IO 完了ポートを使用していますか? またはTask.WhenAll、スレッドがブロックされているためですか?

注意: OP はコメント スレッドで、投稿されたコードには表示されていないタイプミスによる問題であることを確認しています。

DisconnectEx で重複した切断をスケジュールした後、GetQueuedCompletionStatus を使用して通知を受け取ることを期待していました。1 つも取得できません。これは設計によるものですか? OVERLAPPED 構造体で手動リセット イベントを指定すると、これは切断が完了したことを示すために通知されますが、GetQueuedCompletionStatus は返されません。

私の DisconnectEx への呼び出しは、次のようになります (context には演算子 LPOVERLAPPED があり、ol は構造体の最初の要素であることに注意してください)。

GetQueuedCompletionStatus が返されないことがわかったときに、WaitForSingleObject を追加しました。DisconnectEx の完了を検出する正しい方法は何ですか? AcceptEx の呼び出しでソケットを再度使用したい。