(57)【特許請求の範囲】
【請求項１】
一つのプロセッサにより複数のタスクの管理を行うタスク管理システムにおいて、
実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられたディスパッチキューと、
他のモジュール内で動作しているタスクからのサービス依頼によって起動され、上記サービス依頼を処理するサーバタスクと、
上記サーバタスクにサービス依頼を発行するクライアントタスクと、
処理を待っているサービス依頼を記録するデータ構造であるサービス待ちキューと
を備え、
一つのタスクに関する情報を、少なくとも上記タスクの優先度情報を含む上記タスクのスケジューリングに関係する情報を保持するアクティビティと上記アクティビティに記録されていない情報を保持するコンテキストに分割して管理し、
上記アクティビティを上記ディスパッチキューへの挿入または削除の対象としており、
上記サーバタスクは、それ自身の上記アクティビティを持たず、
上記サーバタスクと上記クライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、上記ディスパッチキューおよび上記サービス待ちキューを用いて、上記アクティビティと上記コンテキストの対応関係だけを変化させることにより処理を行うようにしたことを特徴とするタスク管理システム。
【請求項２】
請求項１記載のタスク管理システムにおいて、
上記サーバタスクからのサービス依頼待ちのために上記クライアントタスクが停止しても、即座に上記ディスパッチキューから上記クライアントタスクを削除することなく、上記ディスパッチキューに対する操作を延期することを特徴とするタスク管理システム。
【請求項３】
一つのプロセッサにより複数のタスクの管理を行うタスク管理方法において、
一つのタスクに関する情報を、少なくとも上記タスクの優先度情報を含む上記タスクのスケジューリングに関係する情報を保持するアクティビティと上記アクティビティに記録されていない情報を保持するコンテキストに分割して管理し、
上記アクティビティを実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられたディスパッチキューへの挿入または削除の対象としており、
他のモジュール内で動作しているタスクからのサービス依頼によって起動され、上記サービス依頼を処理するサーバタスクは、それ自身の上記アクティビティを持たず、
上記サーバタスクと上記サーバタスクにサービス依頼を発行するクライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、上記ディスパッチキューおよび処理を待っているサービス依頼を記録するデータ構造であるサービス待ちキューを用いて、上記アクティビティと上記コンテキストの対応関係だけを変化させることにより処理を行うようにしたことを特徴とするタスク管理方法。
【請求項４】
請求項３記載のタスク管理方法において、
上記サーバタスクからのサービス依頼待ちのために上記クライアントタスクが停止しても、即座に上記ディスパッチキューから上記クライアントタスクを削除することなく、上記ディスパッチキューに対する操作を延期することを特徴とするタスク管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、オペレーティング・システム（ＯＳ）に適用して好適なタスク管理システムに関するものである。
【０００２】
【従来の技術】
従来から、タスクの応答時間の上限がデッドラインとなる規定値以下となることを保証しつつ、タスクの実行によって占有可能なプロセッサの時間の有効利用を高めることは、リアルタイムＯＳの重要な設計目標の一つであった。この設計目標を達成するために、より優れたディスパッチポリシを採用することが考えられる。
【０００３】
このようなディスパッチポリシの一つとして、ＥＤＦ（Ｅａｒｌｉｓｔ  Ｄｅａｄｌｉｎｅ  Ｆｉｒｓｔ）ポリシ（参照文献：Ｃ．Ｌ．Ｌｉｕ  ａｎｄ  Ｊ．Ｗ．Ｌａｙｌａｎｄ，“Ｓｃｈｅｄｕｌｉｎｇ  ａｌｏｇｏｒｉｔｈｍｓ  ｆｏｒ  ｍｕｌｔｉｐｒｏｇｒａｍｍｉｎｇ  ｉｎ  ａ  ｈａｒｄ  ｒｅａｌ  ｔｉｍｅ  ｅｎｖｉｒｏｎｍｅｎｔ，”Ｊｏｕｒｎａｌ  ｏｆ  ＡＣＭ，Ｖｏｌ．２０，Ｎｏ．１，ｐｐ．４６−６１，１９７３．）が知られている。ＥＤＦポリシは、デッドラインと周期が等しい周期タスクのスケジューリングを行う手法の中で、もっとも高いプロセッサ利用率を達成可能であることが知られている。ただし、タスク間の干渉がないことや、プロセッサ数が１であることなどの前提条件がある。
【０００４】
一方、システムの安定した動作を実現するために、システムを複数のモジュールに分割し、それぞれを異なるアドレス空間内で実行することによって、互いに他のモジュールのデータを誤って破壊することがないようシステムを構成することが行われている。
【０００５】
また、一般的には、各タスクは個々のモジュールの境界を超えることはできない。このように構成されたシステムにおいて、あるモジュールから他のモジュールの機能を利用することを可能とするために、異なるアドレス空間中の手続きを呼び出すための機構が提供されることが多い。
【０００６】
ところが、この場合、サービスを利用しようとするたびにクライアントタスクとサーバタスクを停止または起動する処理が必要となる。サービスの提供に要する時間にもよるが、しばしば、この停止または起動に要する時間は全サービス時間に対して無視できない割合を占める。さらに、ＥＤＦポリシを採用したスケジューラは、従来のスケジューラに比べてオーバーヘッドが増大する傾向があるため、この問題がさらに悪化することが考えられる。
【０００７】
さらに、サーバタスクの優先度変更に伴うオーバーヘッドの増大も考慮する必要がある。一般に、クライアントタスクの緊急性は様々であるため、サーバタスクはクライアントタスクと同一の優先度で依頼を処理することが望ましい。
【０００８】
そこで、サービス依頼時にサーバタスクの優先度をクライアントタスクの優先度に合わせて変更することがしばしば行われている。この優先度変更または停止に伴うオーバーヘッドの発生が、サーバタスクおよびクライアントタスクの起動または停止に伴うオーバーヘッドに加わることになる。
【０００９】
【発明が解決しようとする課題】
しかし、上述した従来のＥＤＦポリシを採用したスケジューラは、従来のＯＳで広く使われている固定した優先度を用いる静的優先度スケジューラに比べ、オーバーヘッドが大きくなるという不都合があった。
【００１０】
また、サービス依頼時にサーバタスクの優先度をクライアントタスクの優先度に合わせて変更する際に、この優先度変更または停止に伴うオーバーヘッドの発生が、サーバタスクおよびクライアントタスクの起動または停止に伴うオーバーヘッドに加わるため、一層オーバーヘッドが増大するという不都合があった。
【００１１】
そこで、本発明は、かかる点に鑑みてなされたものであり、オーバーヘッドを減少させるために、ディスパッチキューを操作することなく、サーバタスクの起動または停止を行うことができ、また、ディスパッチキューを操作することなく、優先度を継承することができるタスク管理システムを提供することを課題とする。
【００１２】
【課題を解決するための手段】
本発明のタスク管理システムは、単一のプロセッサによりタスクの管理を行うタスク管理システムにおいて、任意のタスクに関する情報のうち、タスクのスケジューリングに関係する情報を保持する第１のデータブロックと、第１のデータブロックに記録されていない情報を保持する第２のデータブロックと、実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられた第３のデータブロックと、他のモジュール内で動作しているタスクからのサービス依頼によって起動され、サービス依頼を処理するサーバタスクと、サーバタスクにサービス依頼を発行するクライアントタスクとを備えるものである。
【００１３】
本発明のタスク管理システムは、特に、一つのタスクに関する情報を、第１のデータブロックと第２のデータブロックに分割して管理し、第１のデータブロックを第３のデータブロックへの挿入または削除の対象としており、サーバタスクは、それ自身の第１のデータブロックを持たない特別のタスクであり、サーバタスクとクライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、第１のデータブロックと第２のデータブロックの対応関係だけを変化させるようにしたものである。
【００１４】
優先度継承プロトコルを採用した同時に二つのタスクの実行をできないようにするミューテックス（Ｍｕｔｅｘ：ＭｕｔｕａｌＥｘｃｌｕｓｉｏｎ（相互排除））が、通常のミューテックスに比べ、オーバーヘッドが大きくなる理由の一つとして、優先度継承による優先度の変化が挙げられる。一般的に、タスクの優先度が変化した際には、ディスパッチキューに対して何らかの操作を行う必要がある。これは、操作に要するコストが大きいＥＤＦスケジューラの場合に特に問題となる。
【００１５】
この分割によって、両者の対応関係を変化させるだけでサーバタスクとクライアントタスクの起動または終了、優先度を継承させることが可能となる。これにより、クライアントタスクが停止したにも関わらず、第１のデータブロックのデータ構造内の位置関係は変化しておらず、第１のデータブロックの関係だけが変化する。
【００１６】
また、起動前における第１のデータブロックから第２のデータブロックに対して、一つのポインタを示す現在有効な対応づけから、起動後における第１のデータブロックから第２のデータブロックに対して、一つのポインタを示す現在有効な対応づけに更新する操作だけで、移動と同等の処理が行われる。
【００１７】
【発明の実施の形態】
本発明の実施の形態を以下に説明する。
本実施の形態のタスク管理システムは、例えば、クライアントタスクがサーバタスクにサービス依頼を行う際に、優先度の継承を効率的に実現するものである。
【００１８】
【課題を解決するための手段】
本発明のタスク管理システムは、一つのプロセッサにより複数のタスクの管理を行うタスク管理システムにおいて、実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられたディスパッチキューと、他のモジュール内で動作しているタスクからのサービス依頼によって起動され、上記サービス依頼を処理するサーバタスクと、上記サーバタスクにサービス依頼を発行するクライアントタスクと、処理を待っているサービス依頼を記録するデータ構造であるサービス待ちキューとを備え、一つのタスクに関する情報を、少なくとも上記タスクの優先度情報を含む上記タスクのスケジューリングに関係する情報を保持するアクティビティと上記アクティビティに記録されていない情報を保持するコンテキストに分割して管理し、上記アクティビティを上記ディスパッチキューへの挿入または削除の対象としており、上記サーバタスクは、それ自身の上記アクティビティを持たず、上記サーバタスクと上記クライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、上記ディスパッチキューおよび上記サービス待ちキューを用いて、上記アクティビティと上記コンテキストの対応関係だけを変化させることにより処理を行うようにしたものである。
【００１９】
また、本発明のタスク管理方法は、一つのプロセッサにより複数のタスクの管理を行うタスク管理方法において、一つのタスクに関する情報を、少なくとも上記タスクの優先度情報を含む上記タスクのスケジューリングに関係する情報を保持するアクティビティと上記アクティビティに記録されていない情報を保持するコンテキストに分割して管理し、上記アクティビティを実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられたディスパッチキューへの挿入または削除の対象としており、他のモジュール内で動作しているタスクからのサービス依頼によって起動され、上記サービス依頼を処理するサーバタスクは、それ自身の上記アクティビティを持たず、上記サーバタスクと上記サーバタスクにサービス依頼を発行するクライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、上記ディスパッチキューおよび処理を待っているサービス依頼を記録するデータ構造であるサービス待ちキューを用いて、上記アクティビティと上記コンテキストの対応関係だけを変化させることにより処理を行うようにしたものである。
【００２０】
この分割によって、コンテキスト（ｃｏｎｔｅｘｔ）４とアクティビティ（ａｃｔｉｖｉｔｙ）２の対応関係を変化させるだけで、サーバタスクの起動または終了、および優先度の継承が可能となる。
【００２１】
図１において、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１は、アクティビティ（ａｃｔｉｖｉｔｙ）２に対して、優先度に基づくもっとも緊急な対応づけ（ｔｈｅ＿ｍｏｓｔ＿ｕｒｇｅｎｔ＿ａｃｔｉｖｉｔｙ）Ｄ１を行っている。
【００２２】
アクティビティ（ａｃｔｉｖｉｔｙ）２は、自身に対して列の後者の対応づけ（ｓｕｃｃｅｓｓｏｒ）Ｄ２を行っている。優先度（ｐｒｉｏｒｉｔｙ）３はアクティビティ（ａｃｔｉｖｉｔｙ）２に対して、列の前者の対応づけ（ｐｒｅｄｅｃｅｓｓｏｒ）Ｄ３を行っている。
【００２３】
コンテキスト（ｃｏｎｔｅｘｔ）４はアクティビティ（ａｃｔｉｖｉｔｙ）２に対して、優先度（ｐｒｉｏｒｉｔｙ）３に関係しない本来の対応づけ（ｂａｓｅ＿ａｃｔｉｖｉｔｙ）Ｄ４を行っている。アクティビティ（ａｃｔｉｖｉｔｙ）２はコンテキスト（ｃｏｎｔｅｘｔ）４に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ５を行っている。
【００２４】
コンテキスト（ｃｏｎｔｅｘｔ）４はアクティビティ（ａｃｔｉｖｉｔｙ）２に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ａｃｔｉｖｉｔｙ）Ｄ６を行っている。
【００２５】
サーバタスクが起動される前後で対応関係が変化する様子を図２に示す。
図２は、サーバ起動によるコンテキストおよびアクティビティの関係の変化を示す図である。図２は、図２Ａに示す起動前から図２Ｂに示す起動後におけるサーバが起動される前後で、コンテキストおよびアクティビティの対応関係が変化する様子を表している。ここでは、キューイングの対象がアクティビティ（ａｃｔｉｖｉｔｙ）であることと、後述するように実行可能でないアクティビティ（ａｃｔｉｖｉｔｙ）もキューイングされることから、このデータ構造をディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）と呼ぶ。
【００２６】
図２から分かるように、クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）１２が停止したにも関わらず、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４はディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１内の同一位置にとどまっており、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４とコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６、コンテキスト（ｃｏｎｔｅｘｔ）Ｃ１３の関係だけが変化している。
【００２７】
複数のクライアント（ｃｌｉｅｎｔ）がサービス（ａ＿ｓｅｒｖｉｃｅ）１５を要求した場合も、サーバタスクの実行が中断されない限り、優先度継承によって常にサーバタスクの優先度が高くなることが保証される。そのため、ディスパッチャがそれらクライアントに対応するコンテキスト（ｃｏｎｔｅｘｔ）をディスパッチ対象として選択する可能性はない。ゆえに、クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）１２に対応づけられていたアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４をディスパッチキュー（ｔｈｅ＿ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１から除去する必要はない。
【００２８】
また、図２Ａに示す起動前におけるアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４からコンテキスト（ｃｏｎｔｅｘｔ）Ｃ１３に対して、一つのポインタを示す現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ１から、図２Ｂに示す起動後におけるアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４からコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６に対して、現在有効な対応づけを示すポインタ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ４に更新する操作だけで、移動と同等の処理が行われている。
【００２９】
さらに、従来の技術に示した手法では、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４がディスパッチキュー（ｔｈｅ＿ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１から除去されていたのに対して、本実施の形態による手法では、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４はそのままディスパッチキュー（ｔｈｅ＿ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１に残される。この処理は、後述する遅延デキューイングによって、この省略が可能となる。
【００３０】
ここで、両者の対応関係の変化の判断は、サービス（ａ＿ｓｅｒｖｉｃｅ）１５のサーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）に対応づけられるコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６が行い、この対応関係の変化を認識する。
【００３１】
図２Ａにおいて、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４はコンテキスト（ｃｏｎｔｅｘｔ）Ｃ１３に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ１を行っている。
【００３２】
サービス（ａ＿ｓｅｒｖｉｃｅ）１５はコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６に対して、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ２を行っている。
【００３３】
図２Ｂにおいて、アクティビティ（ａｃｔｉｖｉｔｙ）１４はコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ４を行っている。
【００３４】
サービス（ａ＿ｓｅｒｖｉｃｅ）１５はコンテキスト（ｃｏｎｔｅｘｔ）Ｃ１３に対して、現在のサービスを記録する（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３を行っている。
【００３５】
サービス（ａ＿ｓｅｒｖｉｃｅ）１５はコンテキスト（ｃｏｎｔｅｘｔ）Ｓ１６に対して、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ２を行っている。
【００３６】
ここで、問題となるのは、サーバタスクの実行が中断されない限りという条件が満たせなくなる場合である。例えば、サーバタスクが入力処理（Ｉ／Ｏ）待ちなどによって停止した場合などがこれに該当する。
【００３７】
この場合、このタスクに対応づけられていたクライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）１２のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４がディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１から除去される。
【００３８】
その結果、後述する図３に示すように、本来ならばサービス完了を待って停止しているはずのクライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２５のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ２（２７）がディスパッチ対象として選択される可能性がある。
【００３９】
この問題を解決するために、サービス完了を待っているクライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）１２は、ディスパッチされた後に、サービス（ａ＿ｓｅｒｖｉｃｅ）１５の実行が完了しているかどうかを検査する。もし、もし完了していなかったならば、自身に対応するアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４をディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１から除去する。ここでは、このように、ディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）１１からアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１４を除去する処理を延期することを、遅延デキューイングと呼ぶ。
【００４０】
図３は、サーバタスクの休眠による不適切なアクティビティの実行を示す図である。
図３において、サーバタスクが、サービス中に停止した場合、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１（２４）がディスパッチキュー（ｔｈｅ  ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）２１から除去される。
【００４１】
これによって、より低い優先度をもち、本来ならば実行されないはずの、アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１（２４）が選択される可能性がある。
【００４２】
このとき、コンテキスト（ｃｏｎｔｅｘｔ）Ｃ２（２６）は、サービス終了後の処理を継続する状態になっている。
【００４３】
したがって、サービスが終了していないにも関わらず、あたかもサービスが終了したかのように動作してしまうことになる。
【００４４】
図３において、クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２２のコンテキスト（ｃｏｎｔｅｘｔ）Ｃ１（２３）は、サービス（ａ＿ｓｅｒｖｉｃｅ）３１に対して、現在のサービスを記録する（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ１１を行っている。
【００４５】
サービス（ａ＿ｓｅｒｖｉｃｅ）３１は、コンテキスト（ｃｏｎｔｅｘｔ）Ｓ３２に対して、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ１２を行っている。
【００４６】
クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２２のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１（２４）は、コンテキスト（ｃｏｎｔｅｘｔ）Ｓ３２に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ１３を行っている。
【００４７】
サービス（ａ＿ｓｅｒｖｉｃｅ）３１は、クライアントタスク（ｃｌｉｅｎｔｔａｓｋ）２５のコンテキスト（ｃｏｎｔｅｘｔ）Ｃ２（２６）に対して、並んで順番を待つ対応づけ（ｉｓ＿ｑｕｅｕｅｄ）Ｄ１４を行っている。
【００４８】
クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２５のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ２（２７）は、コンテキスト（ｃｏｎｔｅｘｔ）Ｃ２（２６）に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ１５を行っている。
【００４９】
サービス（ａ＿ｓｅｒｖｉｃｅ）３１は、クライアントタスク（ｃｌｉｅｎｔｔａｓｋ）２８のコンテキスト（ｃｏｎｔｅｘｔ）Ｃ３（２９）に対して、並んで順番を待つ対応づけ（ｉｓ＿ｑｕｅｕｅｄ）Ｄ１６を行っている。
【００５０】
クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２８のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ３（３０）は、コンテキスト（ｃｏｎｔｅｘｔ）Ｃ３（２９）に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ１７を行っている。
【００５１】
図４は、サービス依頼機構の実現に関連するクラスとそれらの間の関連を示す図である。
図中のディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）３１、アクティビティ（ａｃｔｉｖｉｔｙ）３２およびコンテキスト（ｃｏｎｔｅｘｔ）３４は上述した通りである。
【００５２】
ここでは、その他の二つのクラスについて説明する。この二つのクラスは、それぞれ、以下の機能を有している。
【００５３】
第１に、サービス（ｓｅｒｖｉｃｅ）クラス３７について説明する。
サービス（ｓｅｒｖｉｃｅ）クラス３７は、あるサービス（ｓｅｒｖｉｃｅ）、一般的には、異なるアドレス空間から呼び出し可能な手続きを表現するクラスである。各サービス（ｓｅｒｖｉｃｅ）には、一つのサーバタスクが対応づけられている。このサービス（ｓｅｒｖｉｃｅ）クラス３７のコンテキスト（ｃｏｎｔｅｘｔ）３４はサーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３によるポインタを介して参照可能である。このサービス（ｓｅｒｖｉｃｅ）クラス３７は、アプリケーションプログラムにより生成される。
【００５４】
第２に、サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５について説明する。
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、あるタスクによるサービス要求を表現するクラスである。クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）がサービスを要求してから、サーバタスクがサービスを提供を完了するまでの間、存在し続ける。
【００５５】
属性のインヘリッティング（ｉｎｈｅｒｉｔｉｎｇ）３６は、このサービス（ｓｅｒｖｉｃｅ）要求の処理中に、サーバタスクへの優先度の継承が発生したときにツゥルー（ｔｒｕｅ）、それ以外の場合にフォールス（ｆａｌｓｅ）となる。
【００５６】
このサービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）のコンテキスト（ｃｏｎｔｅｘｔ）により生成される。
【００５７】
次に、オブジェクト間の関係を説明する。
これらのクラスは、それぞれ独立に動作するのではなく、図４に示されているように他のクラスのオブジェクトへの参照の対応づけとして、例えば、ｔｈｅ＿ｆｉｒｓｔ＿ｒｅｑｕｅｓｔを保持している。これらの参照は、以下に挙げるデータ構造を構成するために必要とされている。
【００５８】
第１に、サービス（ｓｅｒｖｉｃｅ）待ちキューについて説明する。
サービス（ｓｅｒｖｉｃｅ）依頼時にサーバタスクが依頼を処理中（ｉｎ＿ｓｅｒｖｉｃｅ）、つまり、あるサービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクトへのポインタが格納されている状態だった場合は、サーバタスクの実行が完了するまで待つことになる。サービス（ｓｅｒｖｉｃｅ）待ちキューは、このようにして待つことになったサービス（ｓｅｒｖｉｃｅ）要求を記録するデータ構造である。サービス（ｓｅｒｖｉｃｅ）待ちキューは、サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクト３５を要素とする双方向リンクリストとして構成されている。
【００５９】
サービス（ｓｅｒｖｉｃｅ）オブジェクト３７のファーストリクエストの対応づけ（ｔｈｅ＿ｆｉｒｓｔ＿ｒｅｑｕｅｓｔ）Ｄ２９が先頭の要素を指している。
【００６０】
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクト３５の列の後者の対応づけ（ｓｕｃｃｅｓｓｏｒ）Ｄ２７は後続する要素３５−１，３５−２・・・へのポインタであり、列の前者の対応づけ（ｐｒｅｄｅｃｅｓｓｏｒ）Ｄ３０は先行する要素３５−１，３５−２・・・へのポインタである。先頭の要素３５の（ｐｒｅｄｅｃｅｓｓｏｒ）Ｄ３０と末尾の要素３５−ｎの（ｓｕｃｃｅｓｓｏｒ）Ｄ２７は、それぞれ、どのオブジェクトも指さない特別なポインタ値を保持している。なお、Ｃ，Ｃ＋＋言語で実装する際にはヌル（ＮＵＬＬ）ポインタをこのために用いることが可能である。
【００６１】
図４において、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）３１は、アクティビティ（ａｃｔｉｖｉｔｙ）３２に対して、優先度に基づくもっとも緊急な対応づけ（ｔｈｅ＿ｍｏｓｔ＿ｕｒｇｅｎｔ＿ａｃｔｉｖｉｔｙ）Ｄ２１を行っている。
【００６２】
アクティビティ（ａｃｔｉｖｉｔｙ）３２は、自身に対して列の後者の対応づけ（ｓｕｃｃｅｓｓｏｒ）Ｄ２２を行っている。優先度（ｐｒｉｏｒｉｔｙ）３３はアクティビティ（ａｃｔｉｖｉｔｙ）３２に対して、列の前者の対応づけ（ｐｒｅｄｅｃｅｓｓｏｒ）Ｄ２３を行っている。
【００６３】
コンテキスト（ｃｏｎｔｅｘｔ）３４はアクティビティ（ａｃｔｉｖｉｔｙ）３２に対して、優先度（ｐｒｉｏｒｉｔｙ）３３に関係しない本来の対応づけ（ｂａｓｅ＿ａｃｔｉｖｉｔｙ）Ｄ２４を行っている。アクティビティ（ａｃｔｉｖｉｔｙ）３２はコンテキスト（ｃｏｎｔｅｘｔ）３４に対して、現在有効な対応づけ（ｅｆｆｅｃｔｉｖｅ＿ｃｏｎｔｅｘｔ）Ｄ２５を行っている。
【００６４】
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、コンテキスト（ｃｏｎｔｅｘｔ）３４に対して、コンテキストの対応づけ（ｔｈｅ＿ｃｏｎｔｅｘｔ）Ｄ２６を行っている。
【００６５】
サービス（ｓｅｒｖｉｃｅ）クラス３７は、サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５に対して、ファーストリクエストの対応づけ（ｔｈｅ＿ｆｉｒｓｔ＿ｒｅｑｕｅｓｔ）Ｄ２９を行っている。
【００６６】
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、サービス（ｓｅｒｖｉｃｅ）クラス３７に対して、ウエイティングフォーの対応づけ（ｗａｉｔｉｎｇ＿ｆｏｒ）Ｄ２８を行っている。
【００６７】
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、３５−１，３５−２・・・に対して、列の後者の対応づけ（ｓｕｃｃｅｓｓｏｒ）Ｄ２７を行っている。サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、３５−１，３５−２・・・に対して、列の前者の対応づけ（ｐｒｅｄｅｃｅｓｓｏｒ）Ｄ３０を行っている。
【００６８】
サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５は、アクティビティ（ａｃｔｉｖｉｔｙ）３２に対して、リクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１を行っている。
【００６９】
サービス（ｓｅｒｖｉｃｅ）クラス３７は、サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス３５に対して、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２を行っている。
【００７０】
サービス（ｓｅｒｖｉｃｅ）クラス３７は、コンテキスト（ｃｏｎｔｅｘｔ）３４に対して、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３を行っている。
【００７１】
次に、サービス要求操作、サーバ処理手順を以下に説明する。
図５は、サービス要求手順の動作を示すフローチャートである。図５に示すサービス要求手順は、サービス（ｓｅｒｖｉｃｅ）クラス３７の動作を示すものである。各処理は、上述した図４に対応している。
【００７２】
図５において、ステップＳ１で、サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクト３５を生成する。ステップＳ２で、サーバタスクはビジーであるか否かを判断する。ステップＳ２でサーバタスクがビジーであるときはステップＳ３へ進み、ステップＳ３で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２による、属性のインヘリッティング（ｉｎｈｅｒｉｔｉｎｇ）３６により、このサービス（ｓｅｒｖｉｃｅ）要求の処理中に、サーバタスクへの優先度の継承が発生したか否かを判断する。
【００７３】
ステップＳ３でサーバタスクへの優先度の継承がされているときはステップＳ４へ進み、ステップＳ４で、ファーストリクエスト（ｔｈｅ＿ｆｉｒｓｔ＿ｒｅｑｕｅｓｔ）Ｄ２９に対応づけられたサービスリクエスト３５からリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）Ｄ３１でアクティビティ３２に対応づけ、さらに、ファーストリクエスト（ｔｈｅ＿ｆｉｒｓｔ＿ｒｅｑｕｅｓｔ）Ｄ２９に対応づけられたサービスリクエスト３５からコンテキスト（ｔｈｅ＿ｃｏｎｔｅｘｔ）の対応づけＤ２６でコンテキスト３４に対応づけることにより、アクティビティ３２とコンテキスト３４の対応づけを行う。
【００７４】
ステップＳ５でサービス（ｓｅｒｖｉｃｅ）待ちキューの先頭に、生成したサービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクト３５を挿入する。
【００７５】
ステップＳ２でサーバタスクがビジーでないときはステップＳ６へ進み、ステップＳ６で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２により、生成したサービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）オブジェクト３５を参照するよう設定する。
【００７６】
ステップＳ３でサーバタスクへの優先度の継承がされていないときはステップＳ７へ進み、ステップＳ７で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）Ｄ３２に対応づけられたサービスリクエスト３５からリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）Ｄ３１でアクティビティ３２に対応づけ、さらに、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）Ｄ３２に対応づけられたサービスリクエスト３５からコンテキスト（ｔｈｅ＿ｃｏｎｔｅｘｔ）の対応づけＤ２６でコンテキスト３４に対応づけることにより、アクティビティ３２とコンテキスト３４の対応づけを行う。
【００７７】
具体的には、サービス要求時のアクティビティ（ａｃｔｉｖｉｔｙ）を現在サービス中のクライアントコンテキストに対応づけする。
【００７８】
ステップＳ８で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２による、属性のインヘリッティング（ｉｎｈｅｒｉｔｉｎｇ）３６において、このサービス（ｓｅｒｖｉｃｅ）要求の処理中に、サーバタスクへの優先度の継承が発生したことを示すツゥルー（ｔｒｕｅ）にする。
【００７９】
ステップＳ９で、現行アクティビティ（ａｃｔｉｖｉｔｙ）３２とサーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３を対応づける。具体的には、先頭クライアントのアクティビティ（ａｃｔｉｖｉｔｙ）とサーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）を対応づけする。
【００８０】
ステップＳ１０で、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３をディスパッチする。このとき、クライアントのコンテキストは保持されている。
【００８１】
ステップＳ１１で、サービス完了か否かを判断する。ステップＳ１１でサービス完了のときは、直ちにサービス要求に成功する。
【００８２】
ステップＳ１１でサービス完了でないときは、ステップＳ１２へ進み、ステップＳ１２で、現行アクティビティ（ａｃｔｉｖｉｔｙ）３２を、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）３１から除去する。具体的には、間違ったディスパッチの修正処理を行う。この処理は、図３に示したクライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）２５のアクティビティ（ａｃｔｉｖｉｔｙ）Ｃ２（２７）の除去に対応する。
【００８３】
ステップＳ１３で、再スケジューリングを行って、ステップＳ１１へ戻って、ステップＳ１１〜ステップＳ１３までの判断および処理を繰り返す。具体的には、本来ディスパッチすべき相手をディスパッチするように処理する。
【００８４】
図６は、サーバ処理手順の動作を示すフローチャートである。図６は、サーバコンテキストの動作を示すものである。
図６において、ステップＳ２１で、サービスを実行する。
【００８５】
ステップＳ２２で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２による、属性のインヘリッティング（ｉｎｈｅｒｉｔｉｎｇ）３６により、このサービス（ｓｅｒｖｉｃｅ）要求の処理中に、サーバタスクへの優先度の継承が発生したか否かを判断する。
【００８６】
ステップＳ２２でサーバタスクへの優先度の継承が発生していないときは、ステップＳ２３へ進み、ステップＳ２３で、ｃをサービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるコンテキストの対応づけ（ｔｈｅ＿ｃｏｎｔｅｘｔ）Ｄ２６とする。具体的には、現在サービスを提供しているクライアントのコンテキストに対応付けする。ステップＳ２４で、待ちキューは空か否かを判断する。
【００８７】
ステップＳ２４で待ちキューが空でないときは、ステップＳ２５へ進み、ステップＳ２５で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２に待ちキューの先頭要素を代入する。
【００８８】
ステップＳ２６で、待ちキューの先頭要素を除去する。ステップＳ２７で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１をされたアクティビティ（ａｃｔｉｂｉｔｙ）３２は遅延デキューイング済みであるか否かを判断する。具体的には、待ちキューに並んでいる間に遅延デキューイングされているときの処理である。
【００８９】
ステップＳ２７で遅延デキューイング済みであるときはステップＳ２８へ進み、ステップＳ２７で遅延デキューイング済みでないときはステップＳ２９へ進む。
【００９０】
ステップＳ２８で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１をされたアクティビティ（ａｃｔｉｂｉｔｙ）３２を、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）３１に挿入する。
【００９１】
ステップＳ２９で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１をされたアクティビティ（ａｃｔｉｂｉｔｙ）３２を、サーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３に対応づける。
【００９２】
ステップＳ３０で、ｃをディスパッチして、ステップＳ２１へ戻って、ステップＳ２１〜ステップＳ３０までの処理および判断を繰り返す。具体的には、以前サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２されていたクライアントをディスパッチする。このとき、以前のアクティビティに対応づけられたコンテキストをディスパッチする必要はない。
【００９３】
ステップＳ２２でサーバタスクへの優先度の継承が発生しているときは、ステップＳ３１へ進み、ステップＳ３１で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１をされたアクティビティ（ａｃｔｉｂｉｔｙ）３２は遅延デキューイング済みであるか否かを判断する。
【００９４】
ステップＳ３１で遅延デキューイング済みであるときはステップＳ３２へ進み、ステップＳ３１で遅延デキューイング済みでないときはステップＳ３３へ進む。
【００９５】
ステップＳ３２で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２によるリクエスティングアクティビティ（ｒｅｑｕｅｓｔｉｎｇ＿ａｃｔｉｂｉｔｙ）の対応づけＤ３１をされたアクティビティ（ａｃｔｉｂｉｔｙ）３２を、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）３１に挿入する。
【００９６】
具体的には、以前のアクティビティは、現行アクティビティよりも優先度の低いもので、サーバーコンテキストに対応づけされるものであるため、以前のアクティビティに対応づけられたコンテキストをディスパッチする必要はない。
【００９７】
ステップＳ３３で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２に待ちキューの先頭要素を代入する。このとき、現在のサービスを記録する（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２が先頭のサービスリクエストを指すようにする。
【００９８】
ステップＳ３４で、待ちキューの先頭要素を除去して、ステップＳ２１へ戻って、ステップＳ２１〜ステップＳ３０までの処理および判断を繰り返す。このとき、サーバコンテキストは、先頭のサービスリクエストに対応づけられたアクティビティで動いていたことになる。
【００９９】
ステップＳ２４で待ちキューが空でのときは、ステップＳ３５へ進み、ステップＳ３５で、サービス処理中（ｉｎ＿ｓｅｒｖｉｃｅ）対応づけＤ３２にＮＵＬＬを代入する。このとき、サーバはアイドリング中である。
【０１００】
ステップＳ３６で、ｃをディスパッチして、ステップＳ２１へ戻って、ステップＳ２１〜ステップＳ３０までの処理および判断を繰り返す。図５に示したステップＳ１０でサーバーコンテキスト（ｓｅｒｖｅｒ＿ｃｏｎｔｅｘｔ）の対応づけＤ３３をディスパッチしたときは、ステップＳ３６でｃをディスパッチしたところで、停止する。
【０１０１】
上述したように、システムの安定性を向上させるためには、システムを複数のモジュールに分割し、それぞれを異なるアドレス空間中で実行することが効果的である。
【０１０２】
また、異なるアドレス空間に存在しているモジュールにサービスを依頼するために、クライアントタスクのサービス依頼を受けてサーバタスクがサービスを実行する機構を提供することが行われている。
【０１０３】
また、このとき、クライアントタスクの緊急性に応じた処理が行えるよう、サーバタスクがクライアントタスクの優先度を継承するよう実装されることがしばしばある。
【０１０４】
一方、より高いプロセッサ利用率を達成するためには、ＥＤＦポリシを採用したスケジューラの利用が効果的である。ところが、ＥＤＦポリシを採用したスケジューラを用いた場合、タスクの起動または終了や、優先度の変更に伴うオーバーヘッドが従来手法に比べて増加する傾向がある。このため、サービス依頼機構の効率が低下するという問題があった。
【０１０５】
そこで、本実施の形態で提案した手法によれば、以下の最適化を可能とすることによって、ＥＤＦスケジューリングがもつディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）操作による高いオーバーヘッドという問題を回避することができる効果がある。
【０１０６】
第１に、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）を表現するデータ構造を操作することなく、サーバタスクを起動または終了する。これによって、ＥＤＦスケジューリングがもつディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）の操作による高いオーバーヘッドという問題を回避することができる。
【０１０７】
第２に、ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）を表現するデータ構造を操作することなく、サーバタスクがクライアントタスクの優先度を継承することを可能とする。この結果、ＥＤＦスケジューリングと優先度継承を伴うサーバタスク起動に付随するオーバーヘッドの増加を抑えつつ、安定性の高いシステム構築と、より高いプロセッサ利用率の達成が可能となる。
【０１０８】
また、この手法を省電力リアルタイムスケジューリング手法と組み合わせることによって、より高い消費電力削減効果を得ることができる。
【０１０９】
【発明の効果】
この発明のタスク管理システムは、単一のプロセッサによりタスクの管理を行うタスク管理システムにおいて、任意のタスクに関する情報のうち、タスクのスケジューリングに関係する情報を保持する第１のデータブロックと、第１のデータブロックに記録されていない情報を保持する第２のデータブロックと、実行可能なタスクの中から、もっとも優先度が高いものを選択するために設けられた第３のデータブロックと、他のモジュール内で動作しているタスクからのサービス依頼によって起動され、サービス依頼を処理するサーバタスクと、サーバタスクにサービス依頼を発行するクライアントタスクとを備え、一つのタスクに関する情報を、第１のデータブロックと第２のデータブロックに分割して管理し、第１のデータブロックを第３のデータブロックへの挿入または削除の対象としており、サーバタスクは、それ自身の第１のデータブロックを持たない特別のタスクであり、サーバタスクとクライアントタスクの起動または終了、およびあるタスクの優先度を他のタスクが継承する際には、第１のデータブロックと第２のデータブロックの対応関係だけを変化させるようにしたので、第１に、第３のデータブロックを操作することなく、サーバタスクを起動または終了することによって、ＥＦＤスケジューリングがもつ第３のデータブロックの操作による高いオーバーヘッドという問題を回避することができる。
【０１１０】
第２に、第３のデータブロックを操作することなく、サーバタスクがクライアントタスクの優先度を継承することを可能とする。この結果、ＥＤＦスケジューリングと優先度継承を伴うサーバタスク起動に付随するオーバーヘッドの増加を抑えつつ、安定性の高いシステム構築と、より高いプロセッサ利用率を達成することができるという効果を奏する。
【０１１１】
また、この発明のタスク管理システムは、上述において、サーバタスクからのサービス依頼待ちのためにクライアントタスクが停止しても、即座に第３のデータブロックからクライアントタスクを削除することなく、誤って第３のデータブロックから選択されることがわかるまで、第３のデータブロックに対する操作を延期するので、クライアントタスクの停止・起動に伴う第３のデータブロックへの操作回数を低減させることができるという効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態に適用されるコンテキストとアクティビティを示す図である。
【図２】サーバ起動によるコンテキストとアクティビティの関係の変化を示す図であり、図２Ａは起動前、図２Ｂは起動後である。
【図３】サーバタスクの休眠による不適切なアクティビティの実行を示す図である。
【図４】サービス依頼機構の実現に関連するクラスとそれらの間の関連を示す図である。
【図５】サービス要求手順の動作を示すフローチャートである。
【図６】サーバ処理手順の動作を示すフローチャートである。
【符号の説明】
１……ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）、２……アクティビティ（ａｃｔｉｖｉｔｙ）、３……コンテキスト（ｃｏｎｔｅｘｔ）、１１……ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）、１２……クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）、１３……コンテキスト（ｃｏｎｔｅｘｔ）Ｃ、１４……アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ、１５……サービス（ａ＿ｓｅｒｖｉｃｅ）、１６……コンテキスト（ｃｏｎｔｅｘｔ）Ｓ、２１……ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）、２２……クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）、２３……コンテキスト（ｃｏｎｔｅｘｔ）Ｃ１、２４……アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ１、２５……クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）、２６……コンテキスト（ｃｏｎｔｅｘｔ）Ｃ２、２７……アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ２、２８……クライアントタスク（ｃｌｉｅｎｔ  ｔａｓｋ）、２９……コンテキスト（ｃｏｎｔｅｘｔ）Ｃ３、３０……アクティビティ（ａｃｔｉｖｉｔｙ）Ｃ３、３１……サービス（ａ＿ｓｅｒｖｉｃｅ）、３２……コンテキスト（ｃｏｎｔｅｘｔ）Ｓ、３１……ディスパッチキュー（ｄｉｓｐａｔｃｈ＿ｑｕｅｕｅ）、３２……アクティビティ（ａｃｔｉｖｉｔｙ）、３３……優先度（ｐｒｉｏｒｉｔｙ）、３４……コンテキスト（ｃｏｎｔｅｘｔ）、３５……サービスリクエスト（ｓｅｒｖｉｃｅ＿ｒｅｑｕｅｓｔ）クラス、３６……インヘリッティング（ｉｎｈｅｒｉｔｉｎｇ）属性、３７……サービス（ｓｅｒｖｉｃｅ）クラス
【図１】
0003870730.tif 000002
【図２】
0003870730.tif 000003
【図３】
0003870730.tif 000004
【図４】
0003870730.tif 000005
【図５】
0003870730.tif 000006
【図６】
0003870730.tif 000007