前回、カーネルモードでのデータ読み取り要求が、最終的にディスクコントローラーにコマンドとして発行されるところまでを解説しました。ほとんどの場合、コマンドの発行は瞬時に完了するため、ディスクデバイスドライバーも「STATUS_PENDING」をすぐに返却します。
全体を通して、ReadFileEx APIの呼び出しから、ERROR_IO_PENDINGの返却までにかかる時間は一瞬、と見て良いでしょう。そして、ユーザーモードのコードは、直後から自由に別の処理を開始する事が出来ます。裏ではディスクコントローラーがハードディスクからデータを読み取るために、ヘッドを目的のトラックに移動しようとしている所です。
ここから、CPUは自由に別の処理を実行する事が出来ます。
さて、しばらくして、ディスクコントローラーがハードディスクからデータを読み取った、としましょう。読み取ったデータはSATA等のインターフェイスでコントローラーに送られてきますが、最初のコマンドに記述されていた通り、所定の物理メモリにこのデータを格納します。これはCPUではなく、ディスクコントローラーが自力でメモリに格納します。この動作を「DMA」（ダイレクトメモリアクセス）と呼びます。
そして、すべからく処理が完了した時点で、CPUに対して「俺、用事あるんだけど？」と通知を行います。この事を「ハードウェア割り込み」と呼びます。
殆どの場合、この通知を受け取ったCPUは、すぐに現在処理中の作業を中断し（後で何事もなく作業続行出来るようにするため、状態を全部記憶し）、「割り込み処理」と呼ばれる特別なメソッドの実行を開始します。
割り込み処理のコードは、ディスクデバイスドライバ内にあります。ここで、ディスクデバイスドライバは、改めてディスクコントローラーに状態を確認し、「あ、さっき要求したコマンドが完了したんだ」と言う事が分かります。なので、すぐにユーザーモードのコードに完了を通知したい…のですが、事は単純ではありません。
CPUは直前まで実行していた「何らかの処理」を放り出して、現在の割り込み処理コードを実行しています。つまり、直前までどのような状態であったのかを知ることは不可能に近いのです。例えば、
- ユーザーモードの.NET ILコードを実行中
- ユーザーモードの.NET CLRのガベージコレクタを実行中
- ユーザーモードのエクスプローラーのアドインコードを実行中
- ユーザーモードのサービスプロセスを実行中
- ユーザーモードのDirectXライブラリを実行中
- カーネルモードのWindowsメモリマネージャを実行中
- カーネルモードのUSBデバイスドライバを実行中
- カーネルモードのプロセススケジューラーを実行中
- カーネルモードのディスプレイドライバを実行中
- カーネルモードで完全にCPUがアイドル状態
など、他にも数限りない状態が考えられます。このような状況で、例えば、処理結果を返却する為に多少のメモリが必要で、動的に確保したいとします。
メモリを確保するには、「ExAllocatePool」カーネルモードAPIを使う事が出来ますが、このAPIの内部処理は、恐らくはWindowsメモリマネージャと、ページング・スワッピングカーネルコードが連携する必要があります。
しかし、上記リストにも示したように、Windowsメモリマネージャの何らかの処理を実行中に、その処理を放り出して割り込み処理を行っているかもしれません。このような状況下でメモリ割り当て処理をそのまま実行しようとすると、ステート管理が破たんする可能性があります。このような問題を「再入処理問題」と呼びます。
従って、割り込み処理の実行中にはメモリ確保は出来ない事になります。他の処理なら可能なのでしょうか？ 少し考えると分かりますが、結局、割り込み処理が実行される直前に何が行われていたのかが分からない限り、あらゆる処理は安全に処理できない可能性が非常に高い事となります。また、分かったとしても、あらゆる状況下を判断して個別に対応する事も、殆ど不可能と言って良いでしょう。
WDM(Windows Driver Model)では、ハードウェア割り込みの割り込み処理中でも安全に処理が可能なAPIを公開しています。しかし、そのようなAPIはごくわずかであり、やはり実作業的な操作は出来ません。一般的に推奨される割り込み処理は、DPC(Deffered Procedure Call・遅延プロシージャコール)キューに、キューエントリーを追加する事です。この処理のために、「IoRequestDpc」カーネルモードAPIを使う事が出来ます。もちろん、このAPIはハードウェア割り込み処理中でも使用可能です。
DPCとは一体何でしょうか？ 何故このような事をする必要があるのでしょうか？
先ほど述べたように、割り込み処理中はあまりに制限が多く、事実上何も出来ないため、「都合のいいタイミングまで処理を遅延」するためにキューを使用します。DPCは割り込み処理コードと同じように、一種のコールバックです。割り込み処理コードでDPCキューにキューエントリーを追加しましたが、このエントリーが「いつかのタイミング」で拾い上げられ、指定されたコールバックが実行されます。このコールバック内なら（若干の制限はありますが）、割り込み処理では実現出来なかった様々な処理を安全に実行する事が出来ます。
一般のユーザーモードデベロッパーはDPCになじみが薄いと思うので、少しだけ垣間見えるものをお見せします。この図はSysinternals Process Explorerの表示です。赤枠の行が、ハードウェア割り込みとDPCの統計を表しています。1秒間当たりの割り込みとDPCコールバックの発生回数を示していますが、安静にしていても結構な回数発生している事が分かります。
DPCが「いつかのタイミング」で実行される、と書きましたが、具体的にはいつでしょうか？ あまり深入りすると複雑なので省きますが、「CPUがアイドル状態」又は「カーネルモードAPI実行の区切りの良いタイミングを通過するスレッド」が、DPCキューからキューエントリを取り出して、コールバックを呼び出します。従って、ここでもワーカースレッドを生成する事はありませんが、後者の場合は、何らかの不特定なスレッド（Arbitrary thread context）を間借りして実行している、と言えます。このタイミングは、Windowsカーネルが完全に管理しているため、タイミングを任意にコントロールする事は出来ず、CPUアイドル実行か不特定スレッドによる実行かを選択する事も出来ません。また、DPCコールバックを実行中は、特定のスレッドに紐づかないため、スレッドを特定する事は無意味となります。
なお、これまでの説明は、CPUが1個のみ（1コア）である事を前提としています。マルチコア・マルチCPUの場合、これらの動作は更に複雑になりますが、基本的には同じ構造を踏襲しています。
さて、これでユーザーモードのコードに処理完了の通知が出来るようになりました。次回はどうやってユーザーモードに通知されるのかを追います。