JPH05120040A - コンピユータシステム - Google Patents

Abstract

(57)【要約】 【目的】資源にプライオリティを持たせ、そのプライオ
リティをタスクのプライオリティに反映させることによ
り、共有資源のロックのためにプライオリティの高いタ
スクの実行が遅れることを最小限に抑える。 【構成】各共有資源のｉｄおよびその資源のプライオリ
ティを管理する共有資源管理テーブルと、各タスクのｉ
ｄ並びにタスク固有のプライオリティとカレントプライ
オリティとを管理しているタスク管理テーブルと、この
タスク管理テーブルのカレントプライオリティを見なが
らタスクのスケジューリングを行なうスケジューラと、
共有資源のロックおよびアンロックに際してタスクのカ
レントプライオリティの書換えを行ない、プライオリテ
ィの変更をスケジューラに知らせる機能を有する共有資
源ロック機構を具備する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータシステム
に関し、詳しくは優先度（プライオリティ）ベースで各
タスクがスケジューリングされるコンピュータシステム
において共有資源へのアクセスを考慮に入れたタクスの
プライオリティの決定方式の改善に関するものである。

【０００２】

【従来の技術】プラテオリティベースで各タスクがスケ
ジューリングされるコンピュータシステムにおける条件
として、次のものがある。 システム上で複数のタスクが実行される。 次にどのタスクを動作させるかを決定するスケジュー
ラがある。 タスクのスケジューリングはプライオリティをベース
にして行う。つまり、その時点で一番プライオリティの
高いタスクを実行する。 現在動作しているタスクより高いプライオリティを持
つタスクが実行可能となると、スケジューラは高いプラ
イオリティのタスクに実行権を与える。 各タスクのプライオリティは事前に既知である。 各タスクが使用する共有資源も事前に既知である。こ
の時、共有資源とハードウェア的なものだけではなく、
ソフトウェア的な資源も含まれる。 タスクが共有資源を利用する場合、つまりクリティカ
ルリージョンに入る場合、タスクはまず共有資源をロッ
クし、資源の利用後（クリティカルリージョンを抜けた
後）ロックを解除（アンロック）する。

【０００３】

【発明が解決しようとする課題】しかしながら、このよ
うなシステムでは次のような問題がある。プライオリテ
ィの違うタスクが３つある場合を例にとって述べる。プ
ライオリティの一番高いタスクをタスクＡ、２番目に高
いタスクをタスクＢ、一番低いタスクをタスクＣとす
る。またタスクＡとタスクＣは同じ共有資源にアクセス
するものとする。この時、タスクＣが共有資源を利用す
るためにクリティカルリージョンに入った後、その資源
を利用するタスクＡが起動されたとする。タスクＡはタ
スクＣがロックした資源を使用できないために、ある時
点でブロックされることになる。このときに中位のプラ
イオリティを持つタスクＢが起動され実行されている
と、高プライオリティを持つタスクＡがタスクＢの終了
を待つことになり、元々システムが期待する高プライオ
リティのタスクを早く終了させるという趣旨に反する動
きをするという問題がある。

【０００４】図４はこの動作（タスクのスケジューリン
グの流れ）を説明するための図である。図中の番号１〜
１０に対応して動作の流れを説明する。 １．低プライオリティのタスクＣが動き始める。 ２．タスクＣは共有資源をロックし、クリティカルリー
ジョンに入る。 ３．高プライオリティのタスクＡが起動される。プライ
オリティベースのスケジューリングが行われるために、
タスクＣは共有資源をロックしたままブロックされる。 ４．中位のプライオリティのタスクＢが起動されるが、
より高いプライオリティのタスクＡが実行されているた
めにブロックされる。 ５．タスクＡはタスクＣがロックしている共有資源を使
用しようとするがブロックされる。そして、タスクＢが
高プライオリティのタスクであるので、タスクＢが実行
権を獲得し実行される。 ６．タスクＢが終了した後、タスクＡは未だに資源が獲
得できずブロックされているので、タスクＣが実行され
る。 ７．タスクＣが共有資源に関するクリティカルリージョ
ンを抜けた後、資源をアンロックする。 ８．ブロックされていたタスクＡが資源を獲得できる状
態になったためにタスクＣがブロックされ、タスクＡが
実行権を獲得する。 ９．タスクＡが実行を終了し、タスクＣが実行される。 １０．タスクＣが実行を終了する。 このように従来のシステムでは、高プライオリティのタ
スクを必ずしも早く終了させることはできなかった。そ
してこのような現象（プライオリティインバージョン）
を解決する十分に効率の良い方法は現在のところ見当た
らない。

【０００５】本発明の目的は、このような点に鑑みてな
されたもので、資源にプライオリティを持たせ、そのプ
ライオリティをタスクのプライオリティに反映させるこ
とにより、共有資源のロックのためにプライオリティの
高いタスクの実行が遅れることを最小限に抑えることが
できるようにしたコンピュータシステムを提供すること
にある。

【０００６】

【課題を解決するための手段】このような目的を達成す
るために、本発明では、プライオリティベースで各タス
クがスケジューリングされるコンピュータシステムであ
って、各共有資源の識別コードおよびその資源のプライ
オリティを管理する共有資源管理テーブルと、各タスク
の識別コード並びにタスク固有のプライオリティとカレ
ントプライオリティとを管理しているタスク管理テーブ
ルと、このタスク管理テーブルのカレントプライオリテ
ィを見ながらタスクのスケジューリングを行なうスケジ
ューラと、共有資源のロックおよびアンロックに際して
タスクのカレントプライオリティの書換えを行ない、プ
ライオリティの変更をスケジューラに知らせる機能を有
する共有資源ロック機構を具備したことを特徴とする。

【０００７】

【作用】各タスクごとにタスクｉｄ、タスクプライオリ
ティ、カレントプライオリティの情報をセットしたタス
ク管理テーブルと、複数のタスクが使用する共有資源に
それぞれリソースプライオリティを設定した共有資源管
理テーブルとを用意し、共有資源を使用するために資源
のロックを行なうタスクには、共有資源ロック機構によ
り当該資源のリソースプライオリティをカレントプライ
オリティに書き込む。スケジューラはカレントプライオ
リティを見てスケジューリングを行なう。これにより資
源のプライオリティを反映したタスクスケジューリング
が行なわれる。

【０００８】

【実施例】以下図面を用いて本発明を詳細に説明する。
本発明では、ロックする必要のある共有資源に関してそ
の資源のｉｄ（認識コード）とその資源をロックするプ
ロセスが得るプライオリティを組にしてリスト形式で保
持しておく。プライオリティは、その共有資源を使用す
る可能性があるタスクの中で一番高いプライオリティを
持つタスクのプライオリティで、システム生成時に固定
した値に設定することもできるが、資源に関するプライ
オリティを設定する関数を設け、実行時に変更すること
も可能である。

【０００９】以下本発明について詳述する。図１は本発
明に係るコンピュータシステムの要部構成図である。図
において、１はスケジューラで、タスク管理テーブル
（後述）のcurrent-priorityを見ながらタスクのスケジ
ューリングを行うものである。２はタスク管理テーブル
であり、各タスクのid（task-id）とプライオリティす
なわちタスクプライオリティ（task-priority ）とカレ
ントプライオリティ（current-priority）を管理してい
るテーブルである。タスクプライオリティはそのタスク
固有のプライオリティであり、カレントプライオリティ
は現在そのタスクがスケジューリングに関して使用され
るプライオリティである。通常はタスクプライオリティ
とカレントプライオリティは同じであるが、当該タスク
が共有資源（図示省略）ロックを行う時に、カレントプ
ライオリティに共有資源ロック機構（後述）がその共有
資源のリソースプライオリティ（resource-priority ）
をセットする。またロックしている資源をアンロックす
る時は共有資源ロック機構が当該タスクのカレントプラ
イオリティをタスクプライオリティの値に戻す。３は共
有資源管理テーブルであり、共有資源のｉｄおよびその
資源のプライオリティすなわちリソースプライオリティ
（resource-priority ）を管理するテーブルである。４
は共有資源ロック機構であり、共有資源のロックまたは
アンロックに際してタスクのカレントプライオリティの
書き替えを行う。更にスケジューラ１にそのプライオリ
ティの変更を知らせる。

【００１０】このような構成における動作を図２に示
す。まず共有資源ロック機構４により共有資源のｉｄか
ら資源のプライオリティを得、タスク管理テーブル２の
当該タスクのカレントプライオリティを共有資源管理テ
ーブルの当該共有資源のリソースプライオリティに変更
する。この時スケジューラ１にそのプライオリティの変
更を知らせる。その後当該共有資源のロックを行なう。
資源の利用後、共有資源のロックが開放され、共有資源
ロック機構４によりタスク管理テーブル２の当該タスク
のカレントプライオリティを自タスクのプライオリティ
の値に戻す（書き換える）。

【００１１】従来例で示したタスクＡ，Ｂ，Ｃの場合に
ついて本発明での動作を図３を参照して説明すると、次
の通りである。 低プライオリティのタスクＣが動き始める。 共有資源をロックし、クリティカルリージョンに入
る。この時タスクＣは、共有資源のプライオリティ、つ
まりタスクＡのプライオリティと同じプライオリティに
なる。 高プライオリティのタスクＡが起動されるが、タスク
Ｃが同じプライオリティで動作しているために実行され
ず、タスクＣが実行を継続する。 中位のプライオリティのタスクＢが起動されるが、よ
り高いプライオリティのタスクＣが実行されているため
にブロックされる。 タスクＣはクリティカルリージョンを抜けると共に、
共有資源のロックを解除し、それと共にプライオリティ
はもともとタスクＡが持っている値に下がる。その結果
タスクＡが一番高プライオリティとなるため、スケジュ
ーラはタスクＡに実行権を与える。 タスクＡの実行終了後、タスクＢが一番高いプライオ
リティを持つため、実行権を獲得し、実行される。 タスクＢが実行を終了し、タスクＣが実行される。 タスクＣが実行を終了する。 以上の動作を従来のシステムにおける場合の動作（図
４）と比べてみると、プライオリティの高いタスクＡを
早く終了させることが出来ていることが明らかである。

【００１２】

【発明の効果】以上説明したように、本発明によれば、
共有資源にプライオリティを付け、そのプライオリティ
をタスクに引き継ぐことにより高プライオリティのタス
クが共有資源が使用できずにブロックされる時間を短縮
でき、プライオリティベースのスケジューリングで所望
の結果を得ることができる。

【図面の簡単な説明】

【図１】本発明に係るコンピュータシステムの一例を示
す要部構成図である。

【図２】共有資源をロックする際の処理の流れを示す図
である。

【図３】本発明におけるタスクのスケジューリングの流
れを説明するための図である。

【図４】従来のシステムにおけるタスクのスケジューリ
ングの流れを説明するための図である。

【符号の説明】

１ スケジューラ ２ タスク管理テーブル ３ 共有資源管理テーブル ４ 共有資源ロック機構

Claims (1)

【特許請求の範囲】
1. 【請求項１】プライオリティベースで各タスクがスケジ
   ューリングされるコンピュータシステムであって、 各共有資源の識別コードおよびその資源のプライオリテ
   ィを管理する共有資源管理テーブルと、 各タスクの識別コードと、タスク固有のプライオリティ
   と現在そのタスクがスケジューリングに関して使用され
   るカレントプライオリティとを管理しているタスク管理
   テーブルと、 このタスク管理テーブルのカレントプライオリティを見
   ながらタスクのスケジューリングを行なうスケジューラ
   と、 前記共有資源のロックおよびアンロックに際してタスク
   の前記カレントプライオリティの書換えを行ない、プラ
   イオリティの変更を前記スケジューラに知らせる機能を
   有する共有資源ロック機構を具備し、共有資源のプライ
   オリティを反映したタスクスケジューリングが行なわれ
   るようにしたことを特徴とするコンピュータシステム。