前回からの続きです。
DPCのキューからキューエントリが取り出されて、DPCコールバックエントリが実行されます。ここで、ディスクデバイスからの結果を処理し(場合によっては、DMAで転送されたデータを移動や加工する)、「I/O要求の完了」とします。
I/O操作を完了するには、「IoCompleteRequest」カーネルモードAPIを呼び出します。これで、STATUS_PENDINGしていた要求が完了した事になります。
但し、(2)で解説した通り、WDMドライバはスタッキングした階層構造になっています。ディスクデバイスの処理が完了しても、そこに至るまでの各階層のドライバが、個別に完了処理を行いたい場合があります。ここではその方法は述べませんが、あらかじめ準備しておけば、これらのドライバも完了と追加処理のタイミングを得る事が出来ます。
重要なのは、この一連の処理は、単一のCPUスタックコンテキスト(スレッドは不明なのでスレッドコンテキストではない)で実行される事です。階層の途中のドライバが再びSTATUS_PENDINGで処理を保留にしない限り、DPCのコールバックからの連続したコールスタックで実行されます。つまり、ここでもワーカースレッドは使われていない、と言う事です。
話を簡単にするため、全ての階層ドライバがI/Oをそのまま完了させたとします。すると、この階層化されたI/Oの要求の出発点である、「ZwReadFile」カーネルモードAPIまで辿ります。ここで本来の(カーネルモード)I/O要求が完了した事になります。
ZwReadFile APIはユーザーモードに遷移して、この事を元のプログラムに通知しなければなりません。ユーザーモードのReadFileEx APIは、処理完了時にAPCコールバックを呼び出す事になっています。しかし、ここに大きな壁があります。
- I/O要求が完了した時、コンテキストはDPCのCPUスタックコンテキストです。そのため、Windowsカーネルから見ると、スレッドさえ良く分からないという微妙な状態にあります。このままでは、ユーザーモードに遷移する事は出来ません。
- ユーザーモードに遷移するためには、呼び出し元のプロセスが特定出来なければなりません。上記のようにスレッドが不明では当然プロセスは特定出来ません。これは2つのパターンがあります。
- DPCがCPUコアのアイドル状態から呼び出された場合は、スレッドは完全に不定です。スレッドが不定では、プロセスも特定出来ません。CPUがアイドリングでストールしている状態を、「アイドルスレッド」のように表現する事がありますが、このようなスレッドが実際に存在するわけではありません。実際、スレッドを管理するためのTEB(Thread environment block)構造体は存在しません。
- DPCが不特定なスレッド(Arbitrary thread context)から呼び出された場合、理論上は何らかのスレッドのスレッドコンテキスト上で実行していることになりますが、このスレッドは、呼び出し元のプロセスとは全く関係ない可能性があります。というよりも、殆どの場合、知らないプロセスの知らないスレッドのスレッドコンテキストを間借りして実行しています。
スレッドについて補足:Windowsカーネルは、全てのプロセスの全てのスレッドを等価に扱います。ユーザーモードから見ると、まずプロセスが存在し、その中にスレッドが存在するように扱われていますが、実際にはすべてがスレッドで、スレッドの一部にプロセスが割り当てられているというイメージです。また、カーネルモードで生成されるスレッドは、特定のプロセスに紐づいていません。この連載で「スレッド」と呼ぶ場合は、これらをひっくるめたすべてのスレッドを指します。
I/O要求を完了するときのDPCを実行するコンテキストが、「偶然に」呼び出し元のスレッドと同じという可能性は殆どあり得ません(タスクマネージャやProcess Explorerで確かめて下さい。Windows稼働時は、常にシステム全体で数千のスレッドが待機しています)。従って、このコンテキストでそのままユーザーモードに遷移し、APCコールバックを呼び出す事は出来ない事になります。
さて、APCコールバックを「APC」と呼んでいる理由を説明する時が来ました。APCの響きはDPCに似ていますね。実は、概念的にAPCとDPCは良く似ています。APCは「Asynchronous Procedure Call」の略で、カーネルモードからユーザーモードに遷移する時に、APCキューに要求を入れ、目的のプロセス空間の目的のスレッドでキューエントリーを取り出して実行するために使います。
DPCキューが割り込み処理からDPCコールバックコンテキストで実行させることを目的としたのに対し、APCキューが異なるスレッドから目的のプロセスのスレッドコンテキストで実行させることに対比出来ます。
(1)の解説で、ユーザーモードのReadFileEx APIからI/O要求を投げていたので、この時のスレッドでAPCキューの内容を取り出して、このスレッドコンテキストでコールバックを実行させる訳です。しかし、このスレッドは、わざわざ非同期I/O処理を要求したので、ReadFileExがERROR_IO_PENDINGを返した直後から、何か別の処理を行っている筈です。そのため、このスレッドが明示的にAPCキューを確認する機会を与える必要があります。
ReadFileEx APIで非同期I/Oを実行した後、何らかの並列実行を行って「手持ちぶたさ」が生じたときに、「SleepEx」ユーザーモードAPI・「WaitForSingleObjectEx」ユーザーモードAPI・「WaitForMultipleObjecstEx」ユーザーモードAPI・「MsgWaitForMultipleObjecstEx」ユーザーモードAPIのいずれかを呼び出すと、APCキューがチェックされ、キューエントリーが存在すると、それに対応したAPCコールバックが実行されます。キューエントリーが無い場合は待機し、新たにキューエントリーが追加されるとAPCコールバックを実行します。
これらのAPIを呼び出していないと、元のスレッドでAPCコールバックを実行する事が出来ないため、キューの内容は保留されたままとなります。
スレッドについて補足しました。