JPH01297760A - タスク制御方式及びオンライン・トランザクション・システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は複数のプロセッサがメモリを共有した密結合マ
ルチ・プロセッサ（Ｔｉｇｈｔｌｙ　　Ｃｏｕｐｌｅｄ
Ｍｕｌｔｉ　　Ｐｒｏｃｅｓｓｏｒ、以下ＴＣＭ’Ｐと
記す）に係わり、特に共有リソースの排他アクセス制御
に好適なロック制御方式に関する。

〔従来の技術〕

旧算機システム内で実行される処理単位（タスク）ＣＪ
、各種の共有リソースを使用する。ＴＣＭＰのように複
数のタスクが同時に動作するシステムでは、これらのタ
スク間で共有リソースの占有使用権に関する競合が発生
するので、このための排他制御が必要となる。例えば−
、オンライン・システムで複数のタスクがそれぞれ別々
の「売上げ処理１を行っている場合、共通の記憶域上に
ある「売上げ現在高」を、別々のタスクが参照・更新す
る。この様な状況では、あるタスクがこの「売−ヒげ現
在高１を参照し、更新している間、別のタスクがこのデ
ータにアクセスすることを禁止する必要がある。

現在実用化されている計算機システムの多くは、排他制
御のための基本機能として、メモリ　（主メモリ）−ヒ
の１ワードの参照と更新を不可分の操作として実行する
命令をハードウェア・レヘルでサポートしている（例え
ば、ＴＥＳＴ　　ＡＮＤ　　ＳＥＴ命令（ＴＳ命令）あ
るいはＣＯＭＰＡＲＥ　　ＡＮＤ　　５ＷＡＰ命令（Ｃ
８命令）等。Ｋ、Ｈｗａ、ｎｇ、　Ｆ、八、Ｂｒ１ｇｇ
５共著ｌｌＣｏｍｐｕｔｅｒＡｒｃｈｉｔｅｃｔｕｒｅ
　　ａｎｄ　　Ｐａｒａｌｌｅｌ　　Ｐｒｏｃｅｓｓｉ
ｎｇ″。

ＭｃＧｒａｗ　　ｌ１ｉｌｌ出版、ｐｐ、５５９〜５６
０参照）。しかし、排他制御の対象となる共有リソース
は、主メモリ上の１ワードとは限らず、ディスク装置上
のデータヘースの場合もある。一般に、この種の共有リ
ソースに対する排他制御は、次のようにして行なわれる
。即ち、主メモリ上に共有リソースのデータ（それぞれ
数ＫＢにも及ぶ多数のデータＡ、Ｂ。

Ｃ２・・・・・・等からなる）の格納領域のほかに、こ
れらのデータを参照するための参照テーブルを設け、こ
のテーブルに前記共有のデータＡ、Ｂ、Ｃ，・・・・・
・にそれぞれ対応して１ワードの参照情＠（ロックワー
ド）を割り当て記述しておく。そして、各データＡ、Ｂ
、Ｃ，・・・・・・に対するアクセスは、このロックワ
ードを通じて行なう。このロックワードに上記の命令を
用いて占有使用中（ロック中）のフラグを書き込むこと
により共有リソースの各データに対する排他制御を実現
することができる。

但し、この方式では共有リソースの占有使用権が得られ
なかった場合の処理が必要となる。この点を考慮した排
他制御方式のひとつとしてＷＡ　Ｉ　Ｔ・ＰＯ８Ｔ方式
（Ｓｕｓｐｅｎｄ−Ｒｅｓｕｍｅ方式、Ｂ　１ｏｃｋ−
Ａｃｔｉｖａｔｅ方式、Ｓ　１ｓｅｐ−Ｗａｋｅｕｐ方
式等とも呼ばれる。上記文献参照）が知られている。

ＷＡＩＴ−ＰＯ５Ｔ方式は、共有リソースがタスク１に
より占有中であった場合に、この共有リソースの占有に
失敗したタスク２を１待ち状態」にするＷＡＩＴ処理と
、タスク１が共有リソースを解放する時に、タスク２の
「待ち状態」を解除するＰＯＳＴ処理（通知処理）によ
って、共有リソースを占有使用権のタスク間排他制御を
行なう（以下、本明細書中で共有リソースの占有使用権
を得る事をロックを取る、ロック権を確保する等表現す
る。又、ロックを取ろうとして、他のタスクが占有使用
中であった為にロックが取れなかった事を、ロック失敗
、ロック確保失敗等と表現する）。

以下の説明で、「実行状態」とは、あるタスクがＣＰＵ
の使用権を得て実際に動作している状態をいい、「実行
可能状態」とは、ＣＰＵが塞がっているため実行できな
いが、ＣＰＵが空きさえすればいつでも実行できるタス
ク状態をいい、一方、「待ち状態」とは、共有リソース
が空いていないため、ＣＰＵが空いても実行できないタ
スク状態をいう。また、共有リソースの使用権は、「占
有使用権」、「占有権」、又は「ロック権」のように表
現する。ＣＰＵの使用については単に「使用権」のよう
に表現する。

各タスクはロック失敗するとＷＡＩＴ処理ルーチンへ制
御を渡す。ＷＡＩＴ処理ルーチンはロック失敗したタス
クを「待ち状態」にし、ディスパッチャを呼び出す。デ
ィスパッチャは、「待ち状態」となったタスクを実行し
ていたＣＰＵに「実行可能状態」の別タスク（第３．第
４．・・・・・・のタスク）を割り当てる。「実行可能
状態」のタスクには、タスク毎にあらかしめ設定した実
行優先順位に従い、ディスパッチャがＣＰＵを割り当て
る。

また一方、各タスク（今まで実行していたタスク）は共
有リソース解放（アンロツタ）直前に「待ち状態」のタ
スク（ＷＡＩＴタスク）の有無を調べ、ＷＡＩＴタスク
があればＰＯＳＴＯ３用−チンへ制御を渡す。ＰＯＳＴ
Ｏ３用−チンはＷＡＩＴタスクを「実行可能状態」に戻
す。「実行可能状態」に戻ったタスクは、後にデイスパ
ツヤによってＣＰＵを割り当てられ、共有リソース占有
使用権を得て処理を再開する。

この様にＷＡＩＴ−ＰＯＳＴ方式では、ＷＡＩＴ処理で
ロック失敗したタスクを「待ち状態」にし、ＰＯＳＴ処
理でこのタスクを「実行可能状態」に戻すことで排他制
御を実現する。以下、ＰＯ８Ｔ処理を起動するタスク（
通常はそれまで実行状態にあったタスク）をＰＯＳＴ発
行タスク、ＰＯＳＴ処理により「待ち状態」を解除され
るＷＡＩＴタスクをＰＯＳＴ受理タスクと呼ぶ（ＰＯＳ
Ｔ発行タスク、ＰＯＳＴ受理タスク、ＷＡＩＴタスク等
は各タスクの固有名称ではない。各タスクがＰＯＳＴ発
行タスクになる場合もあれば、ＰＯ８Ｔ受理タスクにな
る場合もある）。現在実用化されている多くの汎用計算
機システムのスーパーバイザには、上記のＰＯＳＴＯ３
用−チン、ＷＡＩＴ処理ルーチンが組み込まれている。

〔発明が解決しようとする課題〕

ところで、このＷＡＩＴ−ＰＯＳＴ方式には以下の様な
問題点かある。

この問題を第１０図により説明する。第１０図Ｇ４、従
来方式におレフるロック競合発生時のタスクの動作例を
示すタイミング図であって、時間軸は十から下に向かう
方向である。第１０図は、３台のＣＰＵ１．２．３によ
り、複数のタスク１，２゜３．４．５．・・・・・・が
実行される状況を示している。

左下りのハツチ部はタスク１、右下りのハツチ部はタク
ス２、白枠部分ば第３のタスク（タスク３〜５）、相い
梨地状部分はいずれのタスクにも属さないスーパバイザ
（タスク相互の橋渡しを行なう）部、細かい梨地状部分
は、共有リソースに対する１コツク権（占を使用権）を
示す。Ｌ　ＯＧ’　Ｋはロック処理、ｐ　ｏ　ｓ　’ｒ
はボヌト処理、ＦＡＬＬはそこてのタスクによるロック
失敗、Ｄ　Ｉ　Ｓ　Ｉ）はその下に示すタスクに対する
ディスパッチャの処理を示す。

最初に、タスク１はＣＰ　Ｕ　ｌ上でロック権を得（時
刻ｔ１）、次にタスク２はＩコック失敗しく時刻ｔｚ）
待ち状態に入る。タスク１は、これをみ冊 て、共有リソースの使用が終ると、ロック権を手放しタ
スク２にＰＯ８Ｔ処理を発行する（時刻ｔ３）、これに
より、タスク２は御名共有リソースに対するロック権（
占有権）を獲得したことになるが、その時ＣＰＵが空い
ていなため（ＣＰＵの使用権を有しないため）直ちに実
行状態にはならない（実行可能状態）。一方、実行可能
状態の複数のタスクに優先順位があるため、ＣＰＵが空
いたときディスパッチされるタスクは、必ずしも、今通
知を受＆Ｊたタスク２になる訳ではなく、例えば、ＣＰ
Ｕ２が空いたとき、優先順位の高いタスク４が先にディ
スパッチされ（時刻ｔ５〜ｔ６）実行される（１６〜ｔ
’ｓ）ことがある。その場合は、タスク４が先に実行さ
れその処理が終った後に、タスク２がディスパッチされ
実行されることになる（時刻ｔ、〜ｔ８〜ｔｑ）。タス
ク１によるタスク２に対するＰＯＳＴＯ３外らタスク２
による実行状態に移るまでの間に（時刻ｔ３〜ｔｏ）、
タスク３の如き他のＣＰＵ１の別のタスクがロック要求
を発行しても（時刻ｔ４）、この間共有りソースはいず
れのタスクも使っていないのにあたかもロックがかか゛
つた状態になっているためロック失敗となる。

また、タスク２にとって、時刻ｔ３でＰＯＳＴを受理し
ても、他にタスク４のような高実行優先順位のタスクが
あると、このタスク４の処理が実行され終るまで、タス
ク２ばＣＰＵ使用権が得られないことになる。

以上を要約すると、従来技術は次の課題１及び２の問題
点がある。

（課ｕｌｊＰＯＳＴ発行タスク（この場合タスク１）が
Ｉ）　ＯＳ　Ｔ受理タスク（この場合タスク２）に対し
ＰＯ５Ｔ処理を開始した後、ＰＯＳＴ受理タスクがディ
スパッチャによりＣＰＵを害すリ当てられて実行状態に
移るまでの間、ＰＯＳＴ受理タスク以外のタスク　（第
３者のタスク３）か共有リソースを使用できないため、
全処理ステップに対するロック占有ステップの比率（ロ
ック占有率）が高（なり、システムの性能が低下する。

特にマルチ・プロセッサ・システムでは、ＰＯＳＴ発行
タスクがＰＯＳＴＯ３外開始した後、ＰＯＳＴ受理タク
スがディスパッチャによりＣＰＵを割り当てられて実行
状態に移るまでの間、他プロセッサ上で実行中のタスク
がロック要求を発行するため、ロック失敗率（ロック確
保を試みて失敗する確率）が高くなり、ＰＯ５Ｔ処理・
ＷＡ’ｌ　Ｔ処理のオーバーヘッドが増加する。

（課題２）ＰＯＳＴ受理タスクが待ち状態を解除されて
実行可能状態となった時、ＰＯＳＴ受理タスク以外の高
実行優先順位タスクが先にディスパッチされるために、
ＰＯＳＴ受理タスクが即座にＣＰＵ使用権を得られない
場合がある（以下、このように、共有リソースのロック
占有権は得られても、ＣＰＵの使用権を得られない場合
を「ロック占有タスクの沈み込み」と呼ぶ）。ロック占
有タスクが沈め込んだ状態で、他のタスクがロック要求
を発行すると必ずロック失敗してしまい、ＰＯＳＴＯ３
外ＷへＩＴ処理のオーバーヘッドが増加する。

従って、本発明の目的は、上記従来技術の問題点（課題
１及２）を解消し、ＰＯＳＴ受理タスクがディス、ペラ
チャによりＣＰＵを割り当てられて実行状態に移るまで
の間に、第３者のタスクが共有リソースを使用できるよ
うにして、ロック失敗率を低減するとｊＪ：に、ロック
占有タスクの沈み込みを防止して更にロック失敗をなく
したマルチ・タスク方式のマルチ・プロセッサ・システ
ムにおけるロック制御及びタスク制御方式を堤供するこ
とにある。

〔課題を解決するための手段〕

上記課題１を解決するため、本発明のロック制御方式Ｇ
Ａ、つぎの解決手段１又は２のように構成する。

（解決手段１）ＰＯＳＴ全３Ｔスクが該共有リソースの
使用を終了した時点で該共存リソースを解放し、他プロ
セッサ上で実行中の第３のタスクによる該共有リソース
のロックを許可する手段と、しかる後、ＰＯＳＴ処理に
よってＰＯＳＴ受理タスクを実行可能状態に遷移させる
手段と、しかる後、ディスパッチ処理によってプロセッ
サ使用権を得たＰＯＳＴ受理タースクが該共有リソース
のロック権確保をりトライ　（再試行）する手段とを備
えた構成する。

なお、この方式は、ロック占有率を低く抑えることがで
きるので、ロック競合によるスループット低下を起こし
にくいという利点がある。しかし、ＰＯＳＴ受理タスク
がロックを確保する前に他のタスクにロックを「横取り
」され、再度ロック失敗する可能性がある。このため、
同一タスクが何回もリトライを繰返し、レスポンスがや
や低下するおそれがある。この問題は次の（解決手段２
）により解決される。

（解決手段２）ＰＯＳＴ全３Ｔスクが該共有リソースの
使用を終了した時点で該共有リソースを解放し、他プロ
セッサ上で実行中の第３のタスクによる該共有リソース
のロックを許可した後、ＰＯＳＴ処理によってＰＯＳＴ
受理タスクを実行可能状態に遷移し７、しかる後、ディ
スパッチ処理によ−ってプロセッサ使用権を得たＰＯＳ
Ｔ受理タスクが該共有リソースのロック権確保をり１−
ライする第１のロック制御方式と、 ＰＯ５Ｔ発行タスクが該共有リソースの使用を終了した
時点で該共有リソースのロック権をＰＯＳＴ受理タスク
へ直接譲渡し、Ｐ　ＯＳ　Ｔ処理によってＰＯＳＴ受理
タスクを実行可能状態に遷移させた後、ディスパッチ処
理によってプロセッサ使用権を得たＰＯＳＴ受理タスク
が該共有リソースのロック権を解放するまでの間、ＰＯ
３，Ｔ受理タスク以外のタスクによる該共有リソースの
ロックを禁止する第２のロック制御方式とを含み、前記
第１のロック制御方式と第２のロック制御方式とを動的
に切り替える切り替え手段を設ける構成とする。

具体的には、ＰＯＳＴ受理タスクのり１〜ライ回数を計
数し、このリトライ回数が所定の上限値未満ならば、前
記第１のロック制御を行い、リトライ回数が所定の上限
値以上に達すると、前記第２のロック制御を行う構成と
する。つまり、基本的には上記解決手段１の方式を採り
入れるが、ＰＯＳＴ受理タスクが何回もロック権要求し
ても獲得できないときや、特定のリソースを用いるとき
には、ロック権をＰＯＳＴ受理タスクに渡す方式である
。

次に、上記課題２を解決するため、本発明のタスク制御
方式は、つぎの解決手段３，４、及び５のように構成す
る。

（解決手段３）ＰＯＳＴ処理によるＰＯＳＴ受理タスク
の待ち状態解除後、ＰＯＳＴ全３Ｔスクの実行を中断し
、ＰＯＳＴ全３Ｔスクが走行していたプロセッサをＰＯ
ＳＴ受理タスクに割り当てるように構成する。

（解決手段４）ＷＡＩＴ処理によってＰＯＳＴ受理タス
クが待ち状態に遷移する前に、ＰＯＳＴ受理タスクの実
行優先順位を高める優先順位変更を行ない、このＰＯＳ
Ｔ受理タスクの共有リソース解放時に前記変更を施した
実行優先順位を復元するように構成する。

（解決手段５）ＰＯＳＴ全３ＴスクがＰＯＳＴ処理によ
ってＰＯ５Ｔ受理タスクの待ち状態を解除する前に、Ｐ
ＯＳＴ受理タスクの実行優先順位を高める優先順位変更
を行ない、このＰＯＳＴ受理タスクの共有リソース解放
時に前記変更を施した実行優先順位を復元するように構
成する。

〔作用〕

上記構成に基ずく本発明の作用を従来方式と対比して説
明する。なお、この作用については、後で〔実施例〕の
ところで、第１０図〜第１３図によって詳細に説明する
。

まず（解決手段１）の作用について説明する。

従来方式では、さきに第１０図により説明したように、
待ち状態となったタスク２が、タスク１によってＰＯＳ
Ｔされて、ＣＰＵ２で再び実行状態となるまでの期間に
、ＣＰＵ３上で実行中のタスク３がロック失敗してしま
う。これに対し、本発明の（解決手段１）の方式では、
タスク１がＰＯＳＴＯ３間始前に共有リソースを解放す
るまで、待ち状態となったタスク２が、タスク１によっ
てＰＯＳＴされて、ＣＰＵＩで再び実行状態となるまで
の期間に、ＣＰＵａ上で実行中のタスク３が共有リソー
スをロックできる。このためＷＡＩＴ処理、ＰＯＳＴ処
理の回数を減らすことができる（詳細は第１１図により
後述する）。

次に（解決手段２）の作用について説明する。

上述の（解決手段１）の方式では、待ち状態となったタ
スク２が、タスク１によってＰＯＳＴされて実行状態に
戻った後、再びロック失敗する可能性がある。最悪の場
合、タスク２が無限にリトライを繰り返すことになる。

そこで、タスク２のリトライ回数を計数し１、このリト
ライ回数が所定の上限値を越えた場合は、ＰＯＳＴＯ３
間始前に共有リソースを解放しないで、ＰＯＳＴされて
実行状態に戻ったタスク２が確実にロック権を得るよう
にロック制御を切り替える。

次に（解決手段３−５　）の作用について説明する。従
来方式では、タスク１によってＰＯＳＴされたタスク２
がディスパッチされるまでの期間に、ＣＰＵＩ上で実行
中のタスク１やＣＰＵＺ上で実行中のタスク３がロック
失敗している。これに比べ、本発明の（解決手段３〜５
）の方式では、Ｐ○ＳＴ処理の後、タスク２を優先的・
にディスパラチしてＣＰＵＩ上で実行しているので、Ｐ
ＯＳＴＯ３間始からタスク２がディスパッチされるまで
の期間を短縮でき、他タスクのロック失敗を少なくでき
る。

〔実施例〕

以下、本発明の一実施例を第１図から第９図を使って説
明する。本実施例は、オンライン・データベース・シス
テムの例である。

本発明のロック制御方式、タスク制御方式について述べ
る前に、本実施例の適用されるオンライン・データベー
ス・システムの概略を説明する。

なお、本発明はオンラインシステムに限らず、マルチ・
タスク方式のマルチプロセッサ・システム全般に適用で
きる。第７図は、システムの構成概略を表わす。ＣＰＵ
ＩとＣＰＵ２　（１０１および１０２）を共有メモリ１
０３を介して結合する。

２つのＣＰＵは各々メモリ上のプロゲラ１１を動作させ
、メモリ上のデータを参照して、並列に処理を行なうこ
とができる。各ＣＰ　Ｕば、通信制潤製Ｗ２Ｏ３を介し
て、端末装置１０５とデータの送受を行なうことができ
る。また、各ＣＰＵはディスク制窃１装置１０６を介し
て、ディスク」−のデータベース１０７ヘアクセスでき
る。

以下本明細書では、オンライン・データベース・システ
ムでの−まとまりのデータ参照・更新処理をトランザク
ションと呼ぶ。例えば、「預金の引出し要求に対し、預
金残高を確認し、預金残高から引出し額を差引き、デー
タベース内の預金残高を更新する」といった一連の処理
をトランザクションと呼ぶ。トランザクションは、端末
装置からのデータ送信を契機として開始する。

次にタスクの基本的な管理方法について説明する。トラ
ンザクションが入力されると、スーパーバイザがこのト
ランザクシコンに対応する１個以上のタスクを生成する
。具体的には、スーパーバイザがタスクの生成時にタス
ク毎に制御情報を格納したＴＣＢ　（Ｔａｓｋ　Ｃｏｎ
ｔｒｏｌ　　Ｂｌｏｃｋ）を作成し、これらのＴＣＢを
トランザクションの終了時まで第９図に示すタスクキュ
ー１４０に登録して管理する。タスクキューに登録中の
各タスクは、「待ち状態」、「実行可能状態」、または
「実行状態」のいずれかの状態をとる。「待ち状態」の
タスクは、待ちの原因となっている事象を完了し、「実
行可能状態」となるまでＣＰＵを割り付けられない。「
実行可能状態」のタスクは、システム内のいずれかのＣ
ＰＵが空き次第、ＣＰＵを割り付けて「実行状態」に遷
移させることが可能である。「実行状態」のタスクとは
ＣＰＵ使用権を得て実行中のタスクである。「実行可能
状態」のタスクが複数ある場合には、タスク毎に割り当
てた実行優先順位に従って、ディスパッチャがＣＰＵを
割り付ける。タスクキュー１４０は、タスクキュー先頭
ポインタ１４１、タスクキュー末尾ポインタ１４２、お
よび０個以上のＴＣＢ１４３のチエインで構成する。Ｔ
ＣＢは以下のフィールドから構成する（第２図）。

（１）タスク状態４０１ タスクの状態（待ち状態、実行可能状態、または実行状
態）を格納する。

（２）実行優先順位４０２ 該タスクに割り当てた実行優先順位を格納する。

（３）次ＴＣＢポインタ４０３ ＴＣＢをチエインしてタスクキューを構成する際、次の
ＴＣＢアドレスを格納する。タスクキュー末尾のＴＣＢ
の場合は本フィールドはＯを格納する。

（４）タスク情報退避領域４０４ タスクの実行を中断する場合に、該タスクの再開ができ
るように、ＰＳＷ（プログラム状態語）、レジスタ等の
内容を退避するために用いる。

次に本発明のロック競合の制御方式について説明する。

以下、本実施例のオンライン・データベース・システム
ではロック競合の対象となる共有リソースはひとつのデ
ータベースのみと仮定する。

即ち、共有リソースが単一と仮定する。また、各トラン
ザクションによって生成されるタスクも単一とする。即
ち、トランザクションとタスクとの間に１対１の対応が
成り立つ場合を考える。これらの仮定によって、本発明
の方式の利点は失われない。

まず、第１図を用いて本発明のロック制御、タスク制御
方式の概略について説明する。各タスクは共有リソース
をロックする場合、Ｌ　ＯＣＫマクロ５５１を発行し、
ロック処理ルーチン５００を呼び出す。必要な共有リソ
ースが他タスクによって占有使用中の為に確保できない
場合、ロック制御方式の切替え判定（処理５０２）に従
い、ロック制御方式の切替え処理（５０３）を行い、Ｐ
ＯＳＴＯ３間始前に共有リソースを解放する第１のロッ
ク制御方式か、ＰＯＳＴＯ３間始前に共有リソースを解
放しない第２のロック制御方式かを選択する。次に、ス
ーパーバイザ内のＷＡＩＴ処理ルーチン５１０を呼出し
て（５０４）ＬＯＣＫマクロを発行したタスクを「待ち
状態」にする（処理５１１）。この場合、スーパーバイ
ザ内めディスパッチャ５３０が他の「実行可能状態」の
タスクにＣＰＵを割当てる（処理５３’ｌ、５３２）。

ＣＰＵを割当てられたタスクは「実行状態」となす、割
込み等によりＣＰＵ使用権を奪われるまで処理を継続す
る。一方、「待ち状態」となったタスクはＰＯＳＴ処理
によって「実行可能状態」に戻されるまで１待ち状態」
を継続する。

一方、共有リソースを占有使用していたタスクは、共有
リソースをアンロックする場合、ＵＮＬＫマクロ５５２
を発行し、アンロック処理ルーチン５２０を呼び出す。

アンロック処理ルーチンでは、待ち状態のタスクがある
かどうか調べる（処理５２１）。もし、待ち状態のタス
クがあれば、ロック制御方式の切替え処理（５０３）に
より、いずれのロック制御方式が選択されているか判定
する（処理５２２）。ＰＯＳＴＯ３間始前に共有リソー
スを解放する第１のロック制御方式が選択されていれば
、共有リソースを解放しく処理５２３）、ＷＡＩＴタス
クに共有リソース解放を通知する為にＰＯ５Ｔ処理ルー
チンを呼び出す（５２４）。

Ｐ、Ｏ３Ｔ処理開始前に共有リソースを解放しない第２
のロック制御方式が選択されていれば、共有リソースを
解放しないで、ＷＡＩＴタスクに共有リソース解放をｊ
ｍ知する為にＰＯＳＴ処理ルーチンを呼び出す（５２４
，）。

ＰＯＳＴＯ３用−チン５４０ば、ｐ　ｏ　ｓ　′ｒ発行
タスクを「実行状態」から「実行可能状態」に移し、ｐ
　ｏ　ｓ　”ｒ受理タスクを１待ち状態」から「実行可
能状態」に移す（処理５４１）。ロック制御方式の切替
え処理（５０３）により、いずれのロック制御方式が選
択されているか判定する（処理５４２）。第１のロック
制御方式が選択されていれば、ディスパッチャ５３０を
呼び出す（処理５４４）。第２のロック制御方式が選択
されていれば、ＰＯＳＴ受理タスクに優先的にＣＰＵを
割り当てる（処理５４３，５３２）。ＣＰＵ使用権を与
えられたＰＯＳＴ受理タスクは、共有リソースを占有し
て処理を再開することができる。

以上、ＷＡＩＴタスクがひとつの場合について説明して
きたが、一般にはＷＡＩＴタスクが複数存在し得るので
、ＷＡＩＴタスク用の待ち行列（ＷＡＩＴキュー１３０
）を用いる。ロック失敗したタスクは、ＷＡＩＴマクロ
を発行してＷＡＩＴ処理ルーチンをコールする前に、Ｌ
　ＲＢ　（Ｉ−０ＣｋＲｅｑｕｅｓｔ　　Ｂｌｏｃｋの
略）を作成してＷＡＩＴキューにチエインする。また、
各タスクは共有リソースを解放する前に、ＷＡＩＴキュ
ーを参照して待′ら状態のタスクがあるかどうか８周べ
る。もし、希ち状態のタスクかあれば、即ち、ＷＡＩＴ
キューに１個以上Ｌ　ＲＢがチエインしていれば、先頭
の（時間的に最も古い）ＬＲＢ（第７図と第８図で最も
左側のＬＲＢ　１３２）をＷＡＩＴキューから取り出し
、このＬ　Ｒ１３に対応するＷＡＩＴタスクに対して共
有リソース解放を通知するＰＯＳＴマクロを発行する。

次に、このＷＡＩＴキュー１３０および管理ブロックの
データ構造について第３〜４図及び第７〜８図により説
明する。ＷＡＩＴキューは共有メモリ１０３上に設け、
システム内の各タスクからアクセス可能とする。ＷＡＩ
Ｔキューは、各共有リソース毎にひとつ設＋Ｊる。本実
施例では、前述のとおり共有リソースが単一の場合を考
えているので、ＷＡＩＴキューはシステム内に唯一であ
る。

ＷΔＩＴキューは、ひとつのＷＣＢ（ＷＡ、ＩＴＣｏｎ
ｔｒｏｌ　　Ｂ　１ｏｃｋの略）１３１と各タスク毎に
設けた０個以上のＬＲＢ　１３２から構成する。第３図
〜第４図にｗ　ＣＢとＬＲＢの構造を示す。

ＷＣＢには以下の情報を格納する。

（１）ＷＡＩＴキュー・ロックワード３０１Ｗ、ＣＢ自
身の更新の排他制御に用いる。

当ＷＣＢが占有中はロックキーを格納し、解放中は０を
格納する。

（２）リソース・ロックワード３０２ 排他制御の対象となる共有リソースの占有状態を表わす
。共有リソースが占有中はロックキーを格納し、解放中
は０を格納する。

（３）、ＷＡＩＴキュー先頭ポインタ３０３ＷＡＩＴキ
ュー先頭のＬＲＢのアドレスを格納する。ＷＡＩＴキュ
ーが空の場合は０を格納する。

（４）ＷＡＩＴキュー末尾ポインタ３０４ＷＡＩＴキュ
ー末尾のＬＲＢのア下レスを格納する。ＷＡＩＴキュー
が空の場合□は０を格納する。

（５）最大リトライ回数（ＭＡχ−ＲＥＴＲＹ　−ＣＯ
ＵＮＴ）ＷＡＩＴキュー中のＬＲＢ中のりトライ回数の
最大値を示す。

（６）す１〜ライ上限値（ＲＥＴＲＹ、−ＬＩｌ’１ｌ
Ｔ）　３．０６０ツク失敗回数の上限値を示す正整数。

（７）占有タスクＴ　、ＣＢポインタ３０７共有リソー
スを占有中のタスクのＴＣＢアドレスを格納する。共有
リソースが解放中は当フィールドは意味を持たない。

ＬＲ８１３，２には以下の情報を格納する。

（１）　ＥＣＢ（Ｅｖｅｎｔ　　Ｃｏｎｔｒｏｌ　　Ｂ
ｌｏｃｋ）３１１一般にＷＡＩＴ−ＰＯＳＴ方式におい
てＰＯ８Ｔ発行タスクとＷＡＩＴタスクの間で、待ち事
象の発生・未発生を管理する制御情報である。ＰＯＳＴ
Ｏ３上３１２がＯの時は事象未発生、■の時は事象発生
完了を示す。ＷＡＩＴ、１の時はＷＡＩＴ中を示す。本
実施例では、共有リソースの解放を通知する為に用いる
。また、ＥＣＢ内のＰＯＳＴｌ−１’ニーフイールド３
１４を用いてＰＯＳＴ発行タスクからＰ　ＯＳ　Ｔ受理
タスクへロックキーを渡す。

（２）リトライ回数（ＲＥＴＲＹ　−ＣＯＵＮＴ）　３
１５当タスクが何回ロック失敗したかを示すカウンタで
ある。ロックが確保できるとＯクリアする。

（３）次ＬＲＢボインク３１６ Ｌ　ＲＢをチエインしてＷＡＩＴキューを構成する際、
次のり、　ＲＢのアドレスを格納する。

（４）ＷＡＩＴタスクＴＣＢポインタ３１７当Ｌ　ＲＢ
に対応するＷＡＩＴタスクのＴＣＢア・ドレスを格納す
る。

次に共有リソースのロック処理、及びアンロツタ処理の
アルゴリズトについて説明する。尚、以下の説明ではリ
ソース・ロックワード３０２を単にロックワードと呼ぶ
。

共有リソース占有時は占有しているタスクのＴＣＢアド
レスをロックワードに格納し、非占有時は′０をロック
ワードに格納する。ＴＣＢは各タスクに対応して生成す
るので、タスクの識別情報ＩＤとしてＴＣＢアドレスを
用いる。以下、ロックキーとして、このＴＣＢアドレス
を用いるとする。

ます、第５図を用いてロック処理を説明する。

まず、判定処理７０１によって、他タスクからＰＯＳＴ
された後、即ち「待ち状態」の後か否かの判定を行なう
。これはＥＣＢ１．３２内のＰＯＳＴビット３１２が０
か１かにより判定できる。もし、ＰＯＳＴされた後なら
ば、レジスタ１（Ｒ１）に旧ロックキー、即ちＥＣＢ　
１３２内のＰＯ５ＴＯ５上３１４をロードする（処理７
０２）。ｐｏｓＴコードにはＰＯＳＴ発行タスクの識別
情報ＩＤ（ＰＯＳＴ発行タスクのＴＣＢアドレス）が格
納されている。そうでなけれは、レジスタ１に０をロー
ドする（処理７０３）。次に、レジスタ２（Ｒ２）に新
ロックキー、即ち自タスクの識別情報ＴＤ（自タスクの
ＴＣＢアドレス）をロードする（処理７０４）。判定処
理７０５はＣＳ命令を用いて次の様に行なう。

ｃｓ　　Ｒ１，Ｒ２，ＬＯＣＫＩＩＯＲＤこの命令は、
レジスタ１の内容である旧ロックキーとロックワード３
０２のイ直を比較し、もし等しければ、ロックワードの
値をレジスタ２の内容である新ロックキーで置換する（
ロック成功）。

前記の比較の結果が等しくない場合は、ロックワードの
置換を行なわない（ロック失敗）。Ｃ８命令の機能の重
要な点は、上記のロックワードの読み出しから、比較、
更新の間、他のＣＰＵによるロックワードへのアクセス
を禁止できる事である。

これによって、共有リソースが非占有状態の場合、ある
いは、ＰＯＳＴ発行タスクからＰＯＳＴコードとして渡
された旧ロックキーの値がロックワードの現在、（即ち
ＣＳ命令実行時）の値に等しい場合以外は、ロック処理
を試みたタスクはロック失敗となる。

判定処理７０５によって、ロック成功となった場合は、
処理７０６でリトライ回数３１５をＯに戻しロック処理
完了となる。ロック失敗した場合、リトライ回数を１増
加しく処理７０７）　、ＬＲＢを作成しく始めてロック
失敗したとき）又はＬＲＢのりトライ回数を更新しく７
１５）、ＷＡＩＴキュー１３０をロックする（処理７０
８）。他りスフかＷＡＩＴキューをロック中ば、他タス
クの処理が完了するまでループして待つ（７０８ａ）。

ＷＡＩＴキューがロックできたら、す；ライ回数３１５
と最大りトライ回数（ＷＡＩＴキューのチェーン中でリ
トライした回数が最大のもの）３０５を比較する（処理
７０９）。

リトライ回数≧最大リトライ回数 ならば最大リトライ回数を今回のり１−ライ回数に更新
しく処理７１０）、ＷＡＩＴキュー先頭へ（最優先位置
へ）自タスクのＬ　ＲＢをチエインする（処理７１１）
。

リトライ回数〈最大リトライ回数 ならばＷＡＩＴキュー末尾へ自タスクのＬＲＢをチエイ
ンする（処理７１２）。ＷＡ■Ｔキューの更新中（ＷＡ
ＩＴキューをチェーンに繋いだり、チェノからはずした
り、カウンタを書き替える処理中）は、ＷＡＩＴキフー
ーに他のプロセサから入れないように、Ｗ　Ａ　Ｉ　Ｔ
キュー自体ロックされ′ているが、ＬＲＢのＷＡ’ＩＴ
キフー−へのチエインが完了したらＷ、ＡＩＴキューを
解放しく７１３）、ＷＡＩＴマクロを呼び出ずく処理７
１４）。ＷＡＩＴマクロを発行したタスクは「待ち状態
」となり、ＰＯＳＴされるまで「待ち状態」をｍ続する
。

ｐ　ｏ　ｓ　’ｒされろと再度処理７０１Ｌこ戻り、ロ
ック確保を試みる。

尚、ＥＣＢ５１］の初期化（ＰＯ５Ｔビット３１２のク
リア）は処理７０２の直後に行なう。

又、処理７１１および処理７１２では、ＷＡＩＴキュー
のロック時間短縮のため、ＷＡＩＴキュー先頭ポインタ
３０３．、ＷＡＩＴキュー末尾ポインタ３０３を使用し
、ＷＡＩＴキューをサーチする処理は行なわない。又、
ＷＡＩＴキューをロック中は割込タスクとのデッドロッ
ク防止のため、割込禁止とする。

次に第６図を用いてアンロック処理を説明する。

第６図は、第１図のアンロック処理５２０の部分を詳細
に示すものである。アンロック処理では、まずＷＡＩＴ
キューをロックする（処理８０１）。

他タスクがＷ／’、ＩＴキューを占有中は、ロックでき
るまでループして待つ。ＷＡＩＴキューがロックできた
ら、ＷＡ、ＩＴキューが空か否か、即ち、共有リソース
の解放を待っているタスクの有無をチエツクする（処理
８０２）。もし、ＷＡＩＴタスクがなげねば、ＷＡＩＴ
キューおよび共有リソースを解放゛づる（処理８０３〜
８０４）。ＷＡＩ′丁゛ギコーー、共有リソースの解放
は、ロックワード（３０１及び３０２）＆こ０を書き込
む事で行なう。

ＷＡＩ］”タスクがある場合は、まず最大リトライ回数
３０５きりトライ上限値（予じめ設定した値で、ごの値
を境に制御を切換える）３０６を比較する（処理８０５
）。

最大リトライ回数〈リトライ上限値 ならば、即ち、失敗回数が１−限値に達していなげれば
、共有リソースを解放しく処理８０７）、ＰＱＳＴコー
ト３］４にＯをセットする（処理８０８）。

最大リトライ回数≧リトライ上限値 ならば、即ち、失敗回数が上限値に達していれば、ＰＯ
ＳＴコードに現ロックキー、即ち、現ロック権占有タス
ク（現在ロック権を占有中のタスク）の識別情１（ＴＣ
Ｂアドレス３０７）をセラ１〜する（処理８０６）。次
にＷＡＩＴキュー先頭のＬＲＢ（前記最大リトライ回数
を有するタスクに相当）を取り出しく処理８０９）、最
大リトライ回数３０５を更新しく処理８１１または８１
２）、ＷＡＩＴキューを解放しく処理８１３）、処理８
０９にて取り出したＬ　ＲＢに対応するタスクに、ＰＯ
ＳＴマクロを発行しく処理８１４）、共有リソースの解
放を通知する。この時、処理８０６または処理８０８で
セットしたＰＯＳＴコードをＰ○ＳＴ受理タスクへ渡す
。このｐ　ｏ　ｓ　＝「コードは、処理７０２または７
０３　（第５図）によってｐ。

ＳＴ受理タスクが受は取る。この機構により、ｌコック
失敗回数が」二限値未滴の場合は、処理８０７によって
解放した共有リソースは、ＰＯＳＴ受理タスクとそれ以
外のタスクの間で「早い者勝ち」で争われる。しかし、
ロック失敗回数が上限値以」−になった場合、ＰＯ８Ｔ
全８Ｔスクでの共有リソースの解放は行なわず、ｐ　ｏ
　ｓ　”ｒ受理タスクへ直接ロック権を渡す。

次に、上記実施例による作用（動作）を、第１０図ない
し第１３図を用いて従来方式と対比しながら説明する！
これらの図における左下り２右下りのハツチ、梨地状部
、文字記号の意味は１．第１０図について前述したとこ
ろと同じである。

まず（解決手段１）に関する実施例の作用について説明
する。第１０図は、前述したように、従来方式にｉける
ロック競合発生時のタスクの動作例を示すタイミング図
である。第１１図ば（解決手段１）の方式におけるロッ
ク競合発生時のタスクの動作例を示すタイミング図であ
る。第１１図でも、第１０と同じく、ＣＰ　Ｕ　１で実
行中のタスり１によりロック占有中のために、ＣＰＵ２
で実行中のタスク２がロック失敗した場合の動作例を示
している。第１０図に示す従来方式では、前記のように
、待ち状態となったタスク２が、タスク１によってＰＯ
ＳＴされて、ＣＰＵ２で再び実行状態となるまでの期間
に、ＣＰＵ３上で実行中のタスク３がロック失敗してし
まう。これに対し、第１１図に示す（解決手段１の実施
例）の方式では、タスク１がＰＯＳＴＯ３間始（時刻ｔ
ｓ）前に（時刻ｔ３）共有リソースを解放するので、時
刻ｔ４で待ち状態となったタスク２が、タスク１によっ
てＰＯＳＴされて、ＣＰＵＩで再び実行状態となるまで
の期間（時刻ｔ５〜ｔ’ｓ）に、ＣＰＵ３上で実行中の
タスク３が共有リソースをロックできる（時刻ｔ６）。

このためＷＡ　Ｉ　Ｔ処理、ＰＯＳＴ処理の回数を減ら
すことができる。

次に（解決手段２）に関する実施例の作用について説明
する。上述の（解決手段１）の方式では、待ち状態とな
ったタスク２が、タスク１によってＰＯＳＴされて実行
状態に戻った後、再びロック失敗する可能性がある。最
悪の場合、タスク２が無限にリトライを繰り返すことに
なる。そこで、タスク２のりトライ回数を計数し、この
りトライ回数が所定の上限値を越えた場合は、ｐ　ｏ　
ｓ　’ｒ処理開始前に共有リソースを解放しないで、Ｐ
Ｏ３１゛されて実行状態に戻ったタスク２が確実にロッ
ク権を得るようにロック制御を切り替える。ロック失敗
率（ロック確保を試みて失敗する確率）をβ、リトライ
回数の上限値をＮとすると、Ｎ回連続してロック失敗す
る確率はβ８となり、Ｏ〈β〈１であるからβ８は十分
率さな値となる。即ち、リトライ回数が上限値を越えて
、ＰＯＳＴＯ３間始からタスク２か再び実行状態となる
までの期間に渡って共有リソースがロックされる確率（
−βＮ）を極めて小さく抑え、同時にタスク２のリトラ
イ回数をＮ回収下に抑えることができる。

次に（解決手段３〜５）に関する実施例の作用について
説明する。第１２図は従来方式におけるロック競合発生
時のタスクの動作例を示すタイミング図である。第１３
図はく解決手段３〜５）の方式の実施例におけるロック
競合発生時のタスクの動作例を示すタイミング図である
。第１２図。

第１３図ともにＣＰＵＩで実行中のタスク１によりロッ
ク占有中のために、ＣＰＵ２で実行中のタスク２がロッ
ク失敗した場合の動作例を示している。第１２図の従来
方式では、タスク１によってＰＯ８Ｔされたタスク２が
デイスパックされるまでの期間に、ＣＰＵＩ上で実行中
のタスク１やＣＰＵＺ上で実行中のタスク３がロック失
敗している。これに比べ、第１３図の（解決手段３〜５
）の方式では、ＣＰＵＩのタスク１を中断して該ＣＰＵ
Ｉをタスク２に割り当てることによりＰＯ８Ｔ処理（時
刻ｔ４）の後、タスク２を優先的にディスパッチして（
時刻ｔ、）ＣＰＵＩ上で実行しているので、ＰＯＳＴＯ
３間始からタスク２がディスパッチされるまでの期間を
短縮でき、他タスクのロック失敗を少なくできる。また
、これに代えて、タスク２のＷＡＩＴ処理（時刻ｔ３）
でタスク２が待ち状態に遷移する前、又はタスク１のＰ
ＯＳＴ処理（時刻ｔ４）によりタスク２の待ち状態が解
除される前に、タスク２の実行優先順位を高めることに
よって、タスク２はＣＰＵＩ又は他のＣＰＵに優先的に
割り当てられ、同様に上記ｊｌＪ間を短縮できる。

〔発明の効果〕

本発明によれば、オンライン・データヘース・システム
等において、共有リソースの占有使用要求をＷＡＩＴ−
ＰＯＳＴ方式で制御し、かつ、１）Ｏ３Ｔ処理オーバー
ヘッドを共有リソース占有時間から除外でき、かつ、Ｐ
ＯＳＴ受理タスクのりトライ回数増加を一定の上限値以
下に抑え、レスポンスが悪化する現象を回避できるので
、前記システムのスループット性能向上に効果がある。

特にマルチ・プロセッサ・システムの場合、ロック　　
　　　　−占有率を低く抑える本発明の方式は性能向上
に効果がある。

更に、す１〜ライ上限値は各共有リソース毎に設定可能
であり、システムのスルーブツト性能モニタ・プログラ
ムやレスポンス性能モニタ・プログラムと本発明の方式
を統合化し、リトライ上限値を動的に変更することで、
システＪ、全体の性能の自動チューニングを行なうこと
も可能である。

【図面の簡単な説明】

第１図は本発明のロック制御及びタスク制御方式の概略
フローを示す図、第２図はＴ”　ＣＢの形式を示す図、
第３図はＷＣＢの形式を示す図、第４図はＬＲＢの形式
を示す図、第５閾はロック確保処理のフローを示す図、
第６図はロック解放処理のフローを示す図、第７図は本
発明の実施例のマルチ・プロセッサ構成オンライン・デ
ータヘース・システムの構成概略を示す図、第８図はＷ
ＡＩＴキューの形式を示す図、第９図はタスクキューの
形式を示す口、第１０図〜第１３図は本発明の作用を示
す図である。 １３０・・・・・・・・ＷＡＩＴキュー、１３１・・・
・・・・・・ＷＣＢ　　　（ＷＡＩＴ　　　Ｃｏｎｔｒ
ｏｌ　　　旧ｏｃｋ）　　、　　１　３　２−−−１−
１ＲＢ　（Ｌｏｃｋ　　Ｒｅｑｕｅｓｔ　　Ｂｌｏｃｋ
）　、、　　＋　４０−タスクキュー、１４１・・・・
・・・・タスクキュー先頭ポインタ、１４２・・・・・
・・・・タフスキュー末尾ポインタ、１４３−ＴＣＢ　
（Ｔａｓｋ　　Ｃｏｎｔｒｏｌ　　Ｂｌｏｃｋ）、３１
２・・・・・・・・・ＰＯＳＴビ゛ンＩ・、３１３・・
・・　・・Ｗへ］　Ｔヒラｌ−１３１４・・・・・・・
・・Ｐ　ＯＳ　ｉ’コート。 代　理　人　弁理士　弐　顕次部（外１名）″　〒→ 第１１図 第１２Ｎ

Claims (1)

1. 【特許請求の範囲】 １、共有リソースがタスク１により占有使用（ロック）
   中であつたために該共有リソースのロック権確保に失敗
   したタスク２を待ち状態に遷移させるＷＡＩＴ処理と、
   前記タスク１が該共有リソースの使用を終了したときに
   前記タスク２を実行可能状態に遷移させるＰＯＳＴ処理
   と、実行可能状態のタスクにプロセッサ使用権を割り当
   てるディスパッチ処理とによつて、共有リソースの占有
   使用権のタスク間排他制御を行なう、マルチ・タスク方
   式のマルチ・プロセッサ・システムにおけるロック制御
   方式において、タスク１が前記共有リソースの使用を終
   了した時点で該共有リソースを解放し、他プロセッサ上
   で実行中の第３のタスクによる該共有リソースのロック
   を許可する手段と、該ロックの許可後にＰＯＳＴ処理に
   よつてタスク２を実行可能状態に遷移させる手段と、該
   タスク２の実行可能状態への遷移後にディスパッチ処理
   によつてプロセッサ使用権を得たタスク２が前記共有リ
   ソースのロック権確保をリトライする手段とを備えたこ
   とを特徴とするロック制御方式。２、共有リソースがタ
   スク１によりロック中であつたために該共有リソースの
   ロック権確保に失敗したタスク２を待ち状態に遷移させ
   るＷＡＩＴ処理と、前記タスク１が該共有リソースの使
   用を終了したときに前記タスク２を実行可能状態に遷移
   させるＰＯＳＴ処理と、実行可能状態のタスクにプロセ
   ッサ使用権を割り当てるディスパッチ処理とによつて、
   共有リソースの占有使用権のタスク間排他制御を行なう
   、マルチ・タスク方式のマルチ・プロセッサ・システム
   におけるロック制御方式において、 タスク１が該共有リソースの使用を終了した時点で該共
   有リソースを解放し、他プロセッサ上で実行中の第３の
   タスクによる該共有リソースのロックを許可した後、Ｐ
   ＯＳＴ処理によつてタスク２を実行可能状態に遷移させ
   た後、ディスパッチ処理によつてプロセッサ使用権を得
   たタスク２が該共有リソースのロック権確保をリトライ
   する第１のロック制御方式と、 タスク１が該共有リソースの使用を終了した時点で該共
   有リソースのロック権をタスク２へ直接譲渡し、ＰＯＳ
   Ｔ処理によつてタスク２を実行可能状態に遷移させた後
   、ディスパッチ処理によつてプロセッサ使用権を得たタ
   スク２が該共有リソースのロック権を解放するまでの間
   、タスク２以外のタスクによる該共有リソースのロック
   を禁止する第２のロック制御方式とを含み、 前記第１のロック制御方式と第２のロック制御方式とを
   動的に切り替える切り替え手段を備えたことを特徴とす
   るロック制御方式。 ３、前記切り替え手段として、タスク２のリトライ回数
   を計数し、このリトライ回数が所定の上限値未満ならば
   、前記第１のロック制御を行う手段により構成したこと
   を特徴とする請求項２記載のロック制御方式。 ４、前記切り替え手段として、タスク２のリトライ回数
   を計数し、リトライ回数が所定の上限値以上に達すると
   、前記第２のロック制御を行う手段により構成したこと
   を特徴とする請求項２記載のロック制御方式。 ５、ＰＯＳＴ処理によるタスク２の待ち状態解除後、タ
   スク１の実行を中断し、タスク１が走行していたプロセ
   ッサをタスク２に割り当てる手段を備えたことを特徴と
   する請求項２ないし４記載のロック制御方式のためのタ
   スク制御方式。 ６、ＷＡＩＴ処理によつてタスク２が待ち状態に遷移す
   る前に、タスク２の実行優先順位を高める優先順位変更
   を行ない、タスク２の共有リソース解放時に前記変更を
   施した実行優先順位を復元する手段を備えたことを特徴
   とする請求項２ないし４記載のロック制御方式のための
   タスク制御方式。 ７、タスク１がＰＯＳＴ処理によつてタスク２の待ち状
   態を解除する前に、タスク２の実行優先順位を高める優
   先順位変更を行ない、タスク２の共有リソース解放時に
   前記変更を施した実行優先順位を復元する手段を備えた
   ことを特徴とする請求項２ないし４記載のロック制御方
   式のためのタスク制御方式。 ８、請求項１ないし７記載のロック制御方式又はタスク
   制御方式を使用したオンライン・トランザクション・シ
   ステム。