(57)【要約】【課題】  スレッドスケジューリングを使用して、高速Ｉ／Ｏモードの使用を増加させる、デバイスドライバからアプリケーションにデータを配信する。【解決手段】  配信の用意ができているデータを格納するためのデータキュー内のデータ量が少ない場合、システムのスレッドスケジューリングは、デバイスドライバのスレッドを促進するように変更され、アプリケーションによって消費するためのより多くのデータをデータキューに入れる機会をデバイスドライバに与える。デバイスドライバのスレッドの促進は、アプリケーションスレッドから、必ずしもデバイスドライバスレッドとは限らない別のスレッドに切り替える、デバイスドライバスレッドの優先度を上げる、および／またはアプリケーションスレッドの優先度を下げることによって行うことができる。【選択図】  図２
2005092875.tif 000002
【特許請求の範囲】
【請求項１】
デバイスドライバからコンピュータ上で稼働しているアプリケーションにデータを配信するステップを行うコンピュータ実行可能命令を有するコンピュータ可読媒体であって、
前記デバイスドライバによって使用されるデータキュー内のデータをチェックして、前記アプリケーションへの同期配信の用意ができているデータ項目を格納するステップと、
前記データキュー内のデータ量が閾値を超えている場合、前記アプリケーションに前記データキュー内のデータを同期的に配信するステップと、
前記データキュー内のデータ量が閾値を下回っている場合、スレッドスケジューリングによって前記デバイスドライバのスレッドを促進させるステップと
を含むことを特徴とするコンピュータ可読媒体。
【請求項２】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記アプリケーションのスレッドを別のスレッドに譲るステップを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記デバイスドライバの前記スレッドの優先度を上げるステップを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項４】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記アプリケーションの前記スレッドの優先度を下げるステップを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項５】
前記アプリケーションに配信するためにデータ項目を前記デバイスドライバによって第２のドライバのバッファから前記データキューに移動させるステップを実行するコンピュータ可読命令をさらに有することを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項６】
前記データ項目はＷｅｂ要求であることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項７】
第２のドライバによってインターネットからＷｅｂ要求を受信するステップと、
前記受信されたＷｅｂ要求を前記第２のドライバによってバッファに格納するステップと、
前記アプリケーションに同期配信するために前記バッファ内の前記Ｗｅｂ要求を前記デバイスドライバによって前記データキューに移動させるステップと
を実行するコンピュータ可読命令をさらに有することを特徴とする請求項６に記載のコンピュータ可読媒体。
【請求項８】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記コンピュータのスレッドスケジューリングを変更するＡＰＩ機能を呼び出すステップを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項９】
デバイスドライバからスレッドスケジューリングを実施するコンピュータ上で稼働するアプリケーションにデータを配信する方法であって、
前記デバイスドライバによって使用されるデータキュー内のデータをチェックして、前記アプリケーションへの同期配信の用意ができているデータ項目を格納するステップと、
前記データキュー内のデータ量が閾値を超えている場合、前記アプリケーションに前記データキュー内のデータを同期的に配信するステップと、
前記データキュー内のデータ量が閾値を下回っている場合、スレッドスケジューリングによって前記デバイスドライバのスレッドを促進させるステップと
を含むことを特徴とする方法。
【請求項１０】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記アプリケーションのスレッドを別のスレッドに譲るステップを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記デバイスドライバの前記スレッドの優先度を上げるステップを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記アプリケーションのスレッドの優先度を下げるステップを含むことを特徴とする請求項９に記載の方法。
【請求項１３】
前記アプリケーションに配信するためにデータ項目を前記デバイスドライバによって第２のドライバのバッファから前記データキューに移動させるステップをさらに含むことを特徴とする請求項９に記載の方法。
【請求項１４】
前記データ項目はＷｅｂ要求であることを特徴とする請求項９に記載の方法。
【請求項１５】
第２のドライバによってインターネットからＷｅｂ要求を受信するステップと、
前記受信されたＷｅｂ要求を前記第２のドライバによってバッファに格納するステップと、
前記アプリケーションに同期配信するために前記バッファ内の前記Ｗｅｂ要求を前記デバイスドライバによって前記データキューに移動させるステップと
をさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記デバイスドライバの前記スレッドを促進する前記ステップは、前記コンピュータのスレッドスケジューリングを変更するＡＰＩ機能を呼び出すステップを含むことを特徴とする請求項９に記載の方法。
【請求項１７】
コンピュータシステムのスレッドスケジューリングを管理するスレッドマネージャと、
データ項目を処理するアプリケーションと、
前記アプリケーションに配信する用意ができているデータ項目を格納するデータキューと、
前記アプリケーションに配信する用意ができているデータ項目を前記データキューに格納する、前記アプリケーションに前記データ項目を転送するデバイスドライバと
を含み、前記アプリケーションは、前記データキューをチェックし、前記データキュー内のデータ量が閾値を超えると、前記データキューに格納されているデータ項目を同期的に受信し、前記データキュー内のデータ量が前記閾値を下回ると、前記デバイスドライバのスレッドを促進するようにプログラムされている
ことを特徴とするコンピュータシステム。
【請求項１８】
前記アプリケーションは、前記アプリケーションのスレッドを別のスレッドに譲ることによって前記デバイスドライバの前記スレッドを促進することを特徴とする請求項１７に記載のコンピュータシステム。
【請求項１９】
前記アプリケーションは、前記デバイスドライバのスレッドの優先度を上げることによって前記デバイスドライバの前記スレッドを促進することを特徴とする請求項１７に記載のコンピュータシステム。
【請求項２０】
前記アプリケーションは、前記アプリケーションのスレッドの優先度を下げることによって前記デバイスドライバの前記スレッドを促進することを特徴とする請求項１７に記載のコンピュータシステム。
【請求項２１】
前記アプリケーションによって処理されるデータ項目を受信し、前記デバイスドライバによって取り出すために、前記受信されたデータ項目をバッファ内に入れる第２のドライバをさらに含むことを特徴とする請求項１７に記載のコンピュータシステム。
【請求項２２】
前記コンピュータシステムのスレッドスケジューリングを変更するＡＰＩ機能をさらに含み、前記アプリケーションは、前記装置ドライブの前記スレッドを促進するために前記ＡＰＩ機能を呼び出すことを特徴とする請求項１７に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータデータ処理に関し、より詳細には、アプリケーションによって処理するデータを提供する操作に関する。
【背景技術】
【０００２】
データ入出力（Ｉ／Ｏ）は、１つのコンピュータ構成要素から別の構成要素にデータをわたすことを伴い、しばしばデジタル処理での限定要因またはネックとなっている。例えば、コンピュータ上で稼働するアプリケーションは、一般に、例えばカーネルモードなどより低レベルのデバイスドライバが、処理するためのデータをアプリケーションに送り込むことに依存している。したがってアプリケーションの性能は、アプリケーションがそのタスクを実行するのに必要なデータをドライバがどれぐらい効率的に提供することができるかに依存する。
【０００３】
従来、アプリケーションは、２つのモードでデータをデバイスドライバから受信することができる。第１のモードでは、アプリケーションは、要求されたデータが現在使用不可である場合、デバイスドライバからデータを受信する旨の要求を通知（ｐｏｓｔ）する。アプリケーションはデバイスドライバが要求されたデータを提供するのを待たず、要求されたデータは、その後データが使用可能になったときにアプリケーションに配信されるという点で、この要求は非同期的に扱われる。第２のモードでは、データの要求は、同期的に処理される。この場合、要求されたデータは、すでにキューに入れられており、要求に応答して即座に配信されることが可能である。データの配信の非同期の方法は、一般にあまり好ましくない。というのは、データ要求を追跡するためにデータ構造を割り振り、初期化する必要があるため、処理およびメモリのかなりのオーバーヘッド、および非同期の完了のオーバーヘッドをまねくからである。これに対して同期モードでは、こうしたオーバーヘッドはないが、ドライバが、アプリケーションによるシステムコールに応答してピックアップするためにデータをすでにキューに入れていることが必要である。要求されたデータを配信する際に遅延がないため、同期モードは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは「高速Ｉ／Ｏ」とも呼ばれる。ただし、他のプラットフォームでは、異なる用語を使用することもある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
同期方法は、オーバーヘッドをかなり低減し、即座にデータを配信する利点があるため、非同期方法の使用より同期方法の使用を増加させることが望ましい。
【課題を解決するための手段】
【０００５】
上記を鑑み、本発明は、スレッドスケジューリングを使用して、要求されたデータを即座に配信できる確率を向上させることによってアプリケーションへのデータの配信の同期処理、すなわち高速Ｉ／Ｏモードの使用を増加させる、デバイスドライバからアプリケーションにデータを配信するシステムおよび方法を提供する。アプリケーションが処理するためのデータを必要とするとき、アプリケーションに配信する用意ができているデータを格納するためにデバイスドライバによって使用されるデータキューがチェックされる。データキュー内のデータ量が少ない場合、システムのスレッドスケジューリングは、デバイスドライバのスレッドを促進するように変更され、それによってアプリケーションによって消費するためのより多くのデータをデータキューに入れる機会がデバイスドライバに与えられる。デバイスドライバのスレッドの促進は、アプリケーションスレッドから、必ずしもデバイスドライバスレッドとは限らない別のスレッドに切り替える、デバイスドライバスレッドの優先度を上げる、および／またはアプリケーションスレッドの優先度を下げるなどを含めて様々な方法で行うことができる。
【発明を実施するための最良の形態】
【０００６】
図面を参照すると、図中、同様の参照番号は同様の要素を指しており、本発明は、適したコンピューティング環境で実施されるものとして示されている。必須ではないが、本発明を、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明する。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。さらに、本発明は、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成で実施できることを当分野の技術者であれば理解できよう。本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールを、ローカルおよびリモートのメモリ記憶装置に置くことができる。
【０００７】
次の説明は、本発明を実施するために使用できる汎用コンピューティング装置の説明から始め、スレッドスケジューリングによって高速データＩ／Ｏを促進する本発明のシステムおよび方法を、図面２〜５を参照してより詳しく説明する。次に図１を参照すると、汎用コンピューティング装置を、処理ユニット２１、システムメモリ２２、およびシステムメモリを含む様々なシステム構成要素を処理ユニット２１に結合するシステムバス２３を含む従来のパーソナルコンピュータ２０の形で示している。システムバス２３は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。システムメモリは、読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。基本入出力システム（ＢＩＯＳ）２６は、例えば起動中など、パーソナルコンピュータ２０内の要素間での情報の転送を助ける基本ルーチンを含み、ＲＯＭ２４に格納されている。パーソナルコンピュータ２０は、ハードディスク６０から読み取り、あるいはそこに書き込むハードディスクドライブ２７、リムーバブル磁気ディスク２９から読み取り、あるいはそこに書き込む磁気ディスクドライブ２８、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル光ディスク３１から読み取り、あるいはそこに書き込む光ディスクドライブ３０をさらに含む。
【０００８】
ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェイス３２、磁気ディスクドライブインターフェイス３３、および光ディスクドライブインターフェイス３４によってシステムバス２３に接続される。ドライブおよびその関連のコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびパーソナルコンピュータ２０の他のデータの不揮発性記憶装置を提供する。本明細書に記載した環境の例は、ハードディスク６０、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用するが、動作環境の例において、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、読取り専用メモリ、ストレージエリアネットワークなど、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体を使用することもできることを当分野の技術者であれば理解されよう。
【０００９】
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含めて、いくつかのプログラムモジュールをハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納することができる。ユーザは、コマンドおよび情報をキーボード４０およびポインティング装置４２などの入力装置を介してパーソナルコンピュータ２０に入力することができる。図示はしていないが、他の入力装置には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに結合されているシリアルポートインターフェイス４６を介して処理ユニット２１に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）、ネットワークインターフェイスカードなど他のインターフェイスによって接続されていてもよい。モニタ４７または他のタイプの表示装置もまた、ビデオアダプタ４８などのインターフェイスを介してシステムバス２３に接続される。パーソナルコンピュータは一般に、モニタに加えて、図には示していないがスピーカやプリンタなどの他の周辺出力装置を含んでいる。
【００１０】
パーソナルコンピュータ２０は、リモートコンピュータ４９など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルーター、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にパーソナルコンピュータ２０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置５０のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。
【００１１】
ＬＡＮネットワーキング環境で使用する場合、パーソナルコンピュータ２０は、ネットワークインターフェイスまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用する場合、パーソナルコンピュータ２０は一般に、モデム５４、またはＷＡＮ５２を介して通信を確立する他の手段を含む。モデム５４は、内蔵のものでも外付けのものでもよく、シリアルポートインターフェイス４６を介してシステムバス２３に接続される。ネットワーク式環境では、パーソナルコンピュータ２０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。
【００１２】
以下の説明では、特に指定のない限り、１つまたは複数のコンピュータによって実行される動作および操作の象徴を参照して本発明を説明する。したがって、コンピュータで実行されると言うこともあるこうした動作および操作は、コンピュータの処理単位による構造化された形式のデータを表す電気信号の操作を含むことは理解されよう。この操作は、データを変換し、またはコンピュータのメモリシステムのいくつかの場所にデータを維持し、このことは、当分野の技術者にはよく理解されているようにコンピュータを再構成し、そうでない場合はその動作を変更する。データが維持されるデータ構造は、データの形式で定義された特定の特性を有するメモリの物理位置である。しかし、本発明を上記の文脈で説明しているが、これに限定されるものではなく、以下に記載する様々な動作および操作をハードウェアでも実施できることを当分野の技術者であれば理解できよう。
【００１３】
図２を参照すると、本発明は、デバイスドライバ７０からアプリケーション７２へのデータのスループットを向上させるシステムおよび方法を対象にしている。デバイスドライバは、その機能を実行するためにアプリケーションによって要求されたデータを送り込む。アプリケーション７２へのデータ配信の効率を向上させるために、デバイスドライバは、アプリケーションに即座に配信する用意ができているデータを格納するデータキュー７６を維持する。図２に示すように、デバイスドライバ７０は一般に、アプリケーション７２よりコンピュータアーキテクチャのレベルが低い。例えば、デバイスドライバ７０は、オペレーティングシステムのカーネルモードである可能性があり、一方アプリケーション７２は、オペレーティングシステムのユーザモードで稼働する。デバイスドライバ７０は、より低いレベルの別のドライバ８０であるデータソースからデータを受信する可能性がある。データソースは、別のソースからデータを受信する可能性がある。例えば、図２に示した実施形態では、ドライバ８０は、インターネットなどのネットワーク８２からデータを受信する可能性がある。
【００１４】
デバイスドライバ７０からアプリケーション７２にデータを配信するには、アプリケーションによる消費のためにデータキュー７６内に十分なデータがあるかどうかに応じて、２つのモードがある。「低速Ｉ／Ｏ」モードでは、データキュー７６内に十分なデータがなく、アプリケーション７２は、非同期データ配信を要求する。データは、その後デバイスドライバ７０から使用可能になったときに、アプリケーション７２に配信される。低速であることに加えて、非同期データ要求を追跡するためにデータ構造が割り振られ、初期化されなければならないため、このモードのデータ配信には、メモリおよび処理でのオーバーヘッドが高いという短所もある。これに対して「高速Ｉ／Ｏ」モードでは、アプリケーション７２は、同期データ要求を通知し、要求されたデータがアプリケーションに即座に配信される。このモードのデータ配信は、非同期モードのオーバーヘッドのタイプをまねくことがない。さらに、アプリケーションによって必要とされるデータは、アプリケーションから即座に使用可能になる。アプリケーションは、必要なデータを有しているときにのみその機能を実行することができるため、アプリケーションの性能は、アプリケーションがデータを必要としているときにアプリケーションにどれだけ速くデータを配信することができるかに依存する。したがってアプリケーションの性能は、ほとんど常に高速Ｉ／Ｏモードでデータの配信が実行される場合、かなり向上される。当然、高速Ｉ／Ｏモードに必要な状態は、アプリケーション７２によって要求されたデータが、アプリケーションによって消費できるように、データキュー７６内にすでにあることである。
【００１５】
本発明の特徴によれば、高速Ｉ／Ｏのために十分なデータがデータキュー７６内にある確率は、データキューに新しいデータを投入するより多くの機会をデバイスドライバ７０に与えることによって向上し、このことは、スレッドスケジューリングによって達成される。図３を参照すると、高速Ｉ／Ｏモードでデータを配信できるのに十分なデータをデータキュー７６が確実に含むようにするために、ステップ９２でデータキュー７６内のデータ量が時々チェックされる。このチェックは、例えば、アプリケーション７２がより多くのデータを必要とするたびに、しかしアプリケーション７２がデータ要求を発行する前に行うことができる。あるいは、チェックは、例えばドライバ８０などのデータソースが、デバイスドライバのデータをより多く持つようになるたびに行うことができる。データキュー７６内のデータの量が、例えば事前に選択された閾値より少ないなど、少なすぎることがステップ９６で決定されると、コンピュータシステム上で稼働する構成要素のスレッドスケジューリングは、ステップ９８で、デバイスドライバのスレッドを促進して、より多くのデータをデータキューに入れる機会をデバイスドライバに与えるように変更される。本明細書で使用する場合、デバイスドライバスレッドの「促進」とは、デバイスドライバスレッドが稼働される番になるのをより速くすることを意味する。デバイスドライバのスレッドが稼働されると、こうしたデータがソースから入手可能な場合、デバイスドライバ７０は、ステップ１００で、より多くのデータをデータキュー７６に入れることができる。後にアプリケーションスレッドが稼働されると、アプリケーションは、ステップ１０２で、高速Ｉ／Ｏを介してデータキュー内のデータを取り出すことができる。
【００１６】
図２に戻ると、スレッドスケジューリングがどのように変更されるかは、オペレーティングシステムの実施に依存する。例えば、コンピュータの構成要素がスレッドスケジューリングでの優先度を変更する、または他のスレッドに切り替えるために呼び出すアプリケーションプログラミングインターフェイス（ＡＰＩ）機能１１０を提供することができる。一実施形態では、アプリケーション７２は、データを要求する前に、データキュー７６内に十分なデータがあるかどうかをチェックする。データ量が少ないと見なされると、アプリケーションスレッドは、譲る（ｙｉｅｌｄ）というその意志をスレッドマネージャ１２０に知らせるためのＡＰＩ１１０の適切な機能を呼び出すことによって、プロセッサを別のスレッドに譲る。切り替えられる次のスレッドは、デバイスドライバスレッドでなくてもよいことに留意されたい。それでもやはり、そのスレッドを別のスレッドに単に譲ることによって、アプリケーションは、デバイスドライバスレッドに切り替えられる時間を加速し、データ要求を通知する前に、より多くのデータをキューに入れる機会をデバイスドライバに与える。
【００１７】
上述したように、アプリケーションスレッドから別のスレッドに切り替えることに加えて、デバイスドライバスレッドの促進は、デバイスドライバスレッドの優先度を上げる、またはアプリケーションスレッドの優先度を下げることによって行うこともできる。スレッドの優先度の上げ下げは、ＡＰＩ機能の呼出によって行うことができる。一実施形態では、アプリケーション７２またはデバイスドライバ７０は、デバイスドライバスレッドの優先度を上げるためのＡＰＩ１１０を呼び出すことができる。あるいは、またはそれに加えて、デバイスドライバのデータソースは、図２の実施形態ではドライバ８０であり、デバイスドライバスレッドの優先度を上げるためのＡＰＩを呼び出すことができる。
【００１８】
スレッドスケジューリングを使用して高速Ｉ／Ｏを促進する効果を示すために、従来の同期処理の例、および高速Ｉ／Ｏの促進の例をそれぞれ図４および５に示している。こうした２つの例では、アプリケーションは、「Ａｐｐ  Ｐｏｏｌ」と呼ばれ、インターネットから受信されるＷｅｂ要求を満たす（ｓｅｒｖｅ）。この場合、Ａｐｐ  Ｐｏｏｌによって処理されるデータは、Ｗｅｂ要求の形である。Ｗｅｂ要求をＡｐｐ  Ｐｏｏｌに送り込む責任を負うデバイスドライバは、Ｈｔｔｐ．ｓｙｓドライバ１２６である。Ｈｔｔｐ．ｓｙｓドライバ１２６は、要求をインターネットから受信するトランスポートドライバインターフェイス（ＴＤＩ）ドライバ１２８からＷｅｂ要求を受信する。ＴＤＩドライバ１２８は、Ｈｔｔｐ．ｓｙｓドライバによってピックアップされるネットワークから受信するＷｅｂ要求を格納するためのバッファ１３０を有する。同様に、Ｈｔｔｐ．ｓｙｓドライバ１２６は、Ａｐｐ  Ｐｏｏｌ１２２によってピックアップされる要求を格納するためのキュー１３６を有する。
【００１９】
図４に示した例では、本発明の高速Ｉ／Ｏの促進は実施されておらず、Ａｐｐ  Ｐｏｏｌ１２２は、それが処理するデータ、つまりＷｅｂ要求がキュー１３６内にないときに、従来の非同期データ要求を通知する。Ａ〜Ｅとラベル付けされたキュー１３６およびバッファ１３０の連続した５つの状態を図４に示している。矢印１３８は、Ａｐｐ  Ｐｏｏｌ１２２、Ｈｔｔｐ．ｓｙｓドライバ１２６、またはＴＤＩドライバ１２８のどれがプロセッサを有しているか、すなわちどれがそのスレッドを稼働させているかを示すために使用されている。したがって状態Ａでは、Ａｐｐ  Ｐｏｏｌスレッドが稼働している。Ａｐｐ  Ｐｏｏｌ１２２は、Ｗｅｂ要求を受信しようとしたとき、キュー１３６が空であることを発見する。従来通り、Ａｐｐ  Ｐｏｏｌ１２２は、キュー１３６内に２つの「ＩＲＰの受信（ｒｅｃｅｉｖｅ  ＩＲＰｓ）」を通知する。ＩＲＰ（「Ｉ／Ｏ要求パケット」）は、データの非同期配信に使用するデータ構造である。状態Ｂでは、Ｈｔｔｐ．ｓｙｓスレッドが稼働する番である。Ｈｔｔｐ．ｓｙｓは、バッファ１３０から取り出すＷｅｂ要求を使用して通知された２つのＩＲＰの受信を完了する。状態Ｃでは、Ｈｔｔｐ．ｓｙｓは、バッファ１３０内の残りのＷｅｂ要求をキュー１３６に移動させる。状態Ｄでは、Ａｐｐ  Ｐｏｏｌスレッドが戻る。このとき、キュー１３６内には１つのＷｅｂ要求がある。Ａｐｐ  Ｐｏｏｌが処理中、割り込み駆動されているＴＤＩドライバ１２８は、より多くのＷｅｂ要求をバッファ１３０内に入れることができる。状態Ｅでは、Ａｐｐ  Ｐｏｏｌは、高速Ｉ／Ｏを介してキュー１３６内のＷｅｂ要求のみを消費し、再度データ不足を被る。その間、ＴＤＩは、引き続きＷｅｂ要求をバッファに追加し続ける。
【００２０】
図５で示した例では、高速Ｉ／Ｏの促進が実施されている。図５は、Ａ〜Ｃとラベル付けされた３つの状態を示している。Ａｐｐ  Ｐｏｏｌは、呼の受信を行っているときに、キュー１３６内で常にデータ項目を見つけることが好ましい。Ｗｅｂ要求がキュー１３６内にあるとき、呼の受信は、高速Ｉ／Ｏを介して即座に完了される。これは、Ａｐｐ  Ｐｏｏｌがキュー１３６内のデータを使い果たすぎりぎりのときに、Ｈｔｔｐ．ｓｙｓが促進される場合、より頻繁に起こる可能性がある。状態Ａで示すように、Ａｐｐ  Ｐｏｏｌ１２２は、キュー１３６をチェックし、キュー内にはわずかしかデータが残っていないことがわかる。これに応答して、Ａｐｐ  Ｐｏｏｌ１２２は、そのスレッドを譲り、Ｈｔｔｐ．ｓｙｓスレッドの優先度を上げて、Ｈｔｔｐ．ｓｙｓが稼働する可能性が高くなるようにする。状態Ｂでは、Ｈｔｔｐ．ｓｙｓスレッドが稼働し、Ｈｔｔｐ．ｓｙｓドライバは、バッファ１３０からキュー１３６にＷｅｂ要求を移動させる。状態ＣでＡｐｐ  Ｐｏｏｌスレッドが戻ると、高速Ｉ／Ｏを介して取り出す十分なＷｅｂ要求がキュー１３６内にある。キュー１３６内の要求の数が再度少なくなると、Ａｐｐ  Ｐｏｏｌスレッドは、別のスレッドに譲る。
【００２１】
本発明の原理を適用できる多くの可能な実施形態を考慮して、図面を参照して本明細書に記載した実施形態は、例示的なものにすぎず、本発明の範囲を限定するものと見なされるべきではないことを理解されたい。したがって、本明細書に記載した本発明は、頭記の特許請求の範囲、およびその均等物の範囲内に含まれ得るすべての実施形態を含む。
【図面の簡単な説明】
【００２２】
【図１】本発明のディレクトリサービスのオブジェクト割り当て管理を実施できるコンピュータシステムの例を示す概略ブロック図である。
【図２】ドライバからアプリケーションにデータを配信する旨のデータ要求の同期処理、すなわち高速Ｉ／Ｏの使用を促進するために本発明の一実施形態を実施するコンピュータシステムを示す概略図である。
【図３】スレッドスケジューリングを使用して高速Ｉ／Ｏの使用を増加させる方法の概要を示すフロー図である。
【図４】デバイスドライバおよびそのデータキューの様々な状態を、非同期データ配信が従来の方法で使用される一例として示す概略図である。
【図５】デバイスドライバおよびそのデータキューの状態を、本発明の一実施形態によるスレッドスケジューリングの変更によって高速Ｉ／Ｏの使用を促進する効果の一例として示す概略図である。
【符号の説明】
【００２３】
２０  コンピュータ
７０  デバイスドライバ
７２  アプリケーション
７６  データキュー
８０  ドライバ
８２  ネットワーク（インターネット）
１２０  スレッドマネージャ
【図１】
2005092875.tif 000003
【図２】
2005092875.tif 000004
【図３】
2005092875.tif 000005
【図４】
2005092875.tif 000006
【図５】
2005092875.tif 000007
【外国語明細書】
2005092875000001.pdf