JPH07120302B2 - タスクデバッグ方式 - Google Patents
タスクデバッグ方式Info
- Publication number
- JPH07120302B2 JPH07120302B2 JP1123712A JP12371289A JPH07120302B2 JP H07120302 B2 JPH07120302 B2 JP H07120302B2 JP 1123712 A JP1123712 A JP 1123712A JP 12371289 A JP12371289 A JP 12371289A JP H07120302 B2 JPH07120302 B2 JP H07120302B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- state
- tasks
- control block
- debugger
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Debugging And Monitoring (AREA)
Description
【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、多重プログラミング用オペレーティング・シ
ステムに関し、特にタスクデバッグ方式に関する。
ステムに関し、特にタスクデバッグ方式に関する。
情報処理装置においてその情報の処理は、通常プログラ
ムによって行われる。プログラムは、情報を逐次に処理
する。しかし、一般にプログラムは全ての処理が互いに
関連しあい、逐次に処理される必要があるわけではな
い。プログラムを各処理ごとのモジュールに分割し、そ
れぞれを並行動作させて処理を行えば、処理速度は向上
する。
ムによって行われる。プログラムは、情報を逐次に処理
する。しかし、一般にプログラムは全ての処理が互いに
関連しあい、逐次に処理される必要があるわけではな
い。プログラムを各処理ごとのモジュールに分割し、そ
れぞれを並行動作させて処理を行えば、処理速度は向上
する。
このような考え方を「並行プログラミング」といい、各
処理に対応するプログラム・モジュールを「タスク」と
いう。これらのタスクは、オペレーティング・システム
（以下、OSと記す）によって管理される。OSは、タスク
の状態などを考慮してタスクを選択しCPUを割当ててゆ
く。タスクはそれぞれ並行して動作し、互いに同期をと
りデータを通信しながら処理を行ってゆく。
処理に対応するプログラム・モジュールを「タスク」と
いう。これらのタスクは、オペレーティング・システム
（以下、OSと記す）によって管理される。OSは、タスク
の状態などを考慮してタスクを選択しCPUを割当ててゆ
く。タスクはそれぞれ並行して動作し、互いに同期をと
りデータを通信しながら処理を行ってゆく。
いま、次のようなOSを考える。
OSのもとで動作するタスクは、第９図に示した状態遷移
を行うものとする。各状態は、次のような意味をもって
いる。
を行うものとする。各状態は、次のような意味をもって
いる。
・run…OSによってCPUが割当てられている状態。
・ready…全ての条件がそろい、処理の実行が可能な状
態。
態。
・wait…条件が成立するのを待っている状態。
OSは、タスクを第３図に示すようなタスク・コントロー
ル・ブロック（TCB:Task Control Block）によって管理
する。タスク・コントロール・ブロックには、OSがタス
クを管理する上で必要な、優先順位、タスクの状態など
の情報が格納されている。このタスク・コントロール・
ブロックは、第４図に示したように互いにリンクされて
いる。OSは、このリンクの先端と、最後のタスクのタス
ク・コントロール・ブロック・アドレスを持っている。
タスク・コントロール・ブロックは、自分の前と後のタ
スク・コントロール・ブロック・アドレスを持ってお
り、順番にたどってゆくことが可能である。リンクの先
頭のタスク・コントロール・ブロックには自分より前の
タスク・コントロール・ブロックが、リンクの最後のタ
スク・コントロール・ブロックには自分より後のタスク
・コントロール・ブロックが存在しないため、それらの
アドレスエリアには、「０」が入っている。
ル・ブロック（TCB:Task Control Block）によって管理
する。タスク・コントロール・ブロックには、OSがタス
クを管理する上で必要な、優先順位、タスクの状態など
の情報が格納されている。このタスク・コントロール・
ブロックは、第４図に示したように互いにリンクされて
いる。OSは、このリンクの先端と、最後のタスクのタス
ク・コントロール・ブロック・アドレスを持っている。
タスク・コントロール・ブロックは、自分の前と後のタ
スク・コントロール・ブロック・アドレスを持ってお
り、順番にたどってゆくことが可能である。リンクの先
頭のタスク・コントロール・ブロックには自分より前の
タスク・コントロール・ブロックが、リンクの最後のタ
スク・コントロール・ブロックには自分より後のタスク
・コントロール・ブロックが存在しないため、それらの
アドレスエリアには、「０」が入っている。
あるタスクが他のタスクに対する操作をOSに要求する
（システムコールの発行）場合は、タスクを指定する値
としてタスク・コントロール・ブロック・アドレスを指
定する。優先順位とは、OSがタスクを指定選択する基準
として各タスクに与えられているものである。OSは、
「ready」状態のタスクの中から一つを選択し、CPUを割
当てる。OSは、「ready」状態のタスクのうち最も優先
順位と高いタスクにCPUを割当てる。
（システムコールの発行）場合は、タスクを指定する値
としてタスク・コントロール・ブロック・アドレスを指
定する。優先順位とは、OSがタスクを指定選択する基準
として各タスクに与えられているものである。OSは、
「ready」状態のタスクの中から一つを選択し、CPUを割
当てる。OSは、「ready」状態のタスクのうち最も優先
順位と高いタスクにCPUを割当てる。
次に、このようなOSの管理下にあるタスクを動作を、第
10図を参照しながら説明する。
10図を参照しながら説明する。
簡単のために、タスクの数は２つとし、それぞれを「タ
スクＡ」「タスクＢ」と呼ぶ。これらのタスクは、それ
ぞれタスク・コントロール・ブロックTCB−A,タスク・
コントロール・ブロックTCB−Ｂによって管理される。
タスク・コントロール・ブロックはすでに説明したよう
に、互いにリンクされている。第５図は、この様子を示
したものである。タスクの優先順位は、 タスクＡ＞タスクＢ の関係にある。これらのタスクの処理は、セマフォによ
り互いに排除しあいながらI/Oの入出力を行うものとす
る。セマフォとは、オランダのDijkstraによって考案さ
れたタスク間の同期をとるための機構である。主に、OS
が持つ資源のアクセスに関するタスク間の排他制御に用
いられる。このOSにおいては、OSの資源であるI/Oをア
クセスする際の排他制御に用いている。
スクＡ」「タスクＢ」と呼ぶ。これらのタスクは、それ
ぞれタスク・コントロール・ブロックTCB−A,タスク・
コントロール・ブロックTCB−Ｂによって管理される。
タスク・コントロール・ブロックはすでに説明したよう
に、互いにリンクされている。第５図は、この様子を示
したものである。タスクの優先順位は、 タスクＡ＞タスクＢ の関係にある。これらのタスクの処理は、セマフォによ
り互いに排除しあいながらI/Oの入出力を行うものとす
る。セマフォとは、オランダのDijkstraによって考案さ
れたタスク間の同期をとるための機構である。主に、OS
が持つ資源のアクセスに関するタスク間の排他制御に用
いられる。このOSにおいては、OSの資源であるI/Oをア
クセスする際の排他制御に用いている。
セマフォは、タスクから直接操作することはできない。
タスクがセマフォを操作するには、システムコールの形
でOSに要求を出す。
タスクがセマフォを操作するには、システムコールの形
でOSに要求を出す。
まず、セマフォを要求するシステムコールは、「wai-se
m」である。このシステムコールにより、タスクはセマ
フォを獲得することができる。もし、セマフォが他のタ
スクに獲得されている場合は、このシステムコールを発
行したタスクは、第９図の状態遷移図に従い、「run」
状態から「wait」状態へ遷移する。
m」である。このシステムコールにより、タスクはセマ
フォを獲得することができる。もし、セマフォが他のタ
スクに獲得されている場合は、このシステムコールを発
行したタスクは、第９図の状態遷移図に従い、「run」
状態から「wait」状態へ遷移する。
セマフォを返すシステムコールは、「sig-sem」であ
る。このシステムコールによりタスクは、獲得している
セマフォをOSに返す。この時、セマフォを獲得できずに
「wait」状態になっているタスクがあれば、この時点で
セマフォを獲得でき、「ready」状態へと遷移する。
る。このシステムコールによりタスクは、獲得している
セマフォをOSに返す。この時、セマフォを獲得できずに
「wait」状態になっているタスクがあれば、この時点で
セマフォを獲得でき、「ready」状態へと遷移する。
はじめに、２つのタスクは「ready」状態にある。優先
順位はタスクＡの方が高いため、OSはタスクＡにCPUを
割当てる（第10図の）。タスクＡは、I/Oの入出力の
ため「wai-sem」システムコールによってセマフォを獲
得する。セマフォを獲得したタスクＡは、I/Oとの同期
をとるために「wai-tsk」システムコールによって一定
時間「wait」状態に入る（第10図の）。
順位はタスクＡの方が高いため、OSはタスクＡにCPUを
割当てる（第10図の）。タスクＡは、I/Oの入出力の
ため「wai-sem」システムコールによってセマフォを獲
得する。セマフォを獲得したタスクＡは、I/Oとの同期
をとるために「wai-tsk」システムコールによって一定
時間「wait」状態に入る（第10図の）。
タスクＡが「wait」状態に入ったことにより、OSはタス
クＢにCPUを割当てる。タスクＢは、タスクＡと同時にI
/Oの入出力を行うために「wai-sem」システムコールを
発行する。しかし、セマフォは、すでにタスクＡが獲得
しているために、タスクＢは「wait」状態に遷移する
（第10図の）。２つのタスクが共に「wait」状態に入
ったことにより、CPUはタスクが割当てられていない状
態に入る（第10図の）。
クＢにCPUを割当てる。タスクＢは、タスクＡと同時にI
/Oの入出力を行うために「wai-sem」システムコールを
発行する。しかし、セマフォは、すでにタスクＡが獲得
しているために、タスクＢは「wait」状態に遷移する
（第10図の）。２つのタスクが共に「wait」状態に入
ったことにより、CPUはタスクが割当てられていない状
態に入る（第10図の）。
指定時間が経過するとタスクＡは、「wait」状態から
「ready」状態へ遷移し、I/O処理を再開する（第10図の
）。I/O処理が完了すると、タスクＡは「sig-sem」シ
ステムコールによって、獲得していたセマフォをOSへ返
す。返されたセマフォは、セマフォが獲得できずに「wa
it」状態に遷移したタスクＢに与えられる。この時点で
タスクＢは、「ready」状態へ遷移する（第10図の
）。しかし、タスクＢはタスクＡが「ready」状態で
あるため、CPUは割当てられない。タスクＡでの処理が
進み、他の要因でタスクＡが「wait」状態に遷移する
と、タスクＢにCPUが割当てられる（第10図の）。
「ready」状態へ遷移し、I/O処理を再開する（第10図の
）。I/O処理が完了すると、タスクＡは「sig-sem」シ
ステムコールによって、獲得していたセマフォをOSへ返
す。返されたセマフォは、セマフォが獲得できずに「wa
it」状態に遷移したタスクＢに与えられる。この時点で
タスクＢは、「ready」状態へ遷移する（第10図の
）。しかし、タスクＢはタスクＡが「ready」状態で
あるため、CPUは割当てられない。タスクＡでの処理が
進み、他の要因でタスクＡが「wait」状態に遷移する
と、タスクＢにCPUが割当てられる（第10図の）。
以上のように、２つのタスクは互いに排除しあいながら
処理を行う。
処理を行う。
次に、上記のタスクを同じOS上でタスクとして実現され
ているデバッガでデバッグすることを考えてみる。デバ
ッガとタスクＡ、タスクＢの優先順位の関係は、次のと
おりである。
ているデバッガでデバッグすることを考えてみる。デバ
ッガとタスクＡ、タスクＢの優先順位の関係は、次のと
おりである。
デバッガ＞タスクＡ＞タスクＢ デバッグの方法は、ブレークポイントを用いる。ブレー
クポイントとは、タスク実行を停止させる時点のことで
ある。タスクがブレークポイントまで実行すると、「wa
it」状態にあるデバッガが起動され、タスクを「wait」
状態に遷移させることにより実現される。
クポイントとは、タスク実行を停止させる時点のことで
ある。タスクがブレークポイントまで実行すると、「wa
it」状態にあるデバッガが起動され、タスクを「wait」
状態に遷移させることにより実現される。
いま、ブレークポイントが、タスクＡのセマフォ獲得動
作の前に設定されているものとする。この時のタスク
Ａ、タスクＢの動作を第11図を参照しながら説明する。
簡単のために、第11図では、デバッガの動作の図示は省
略してある。
作の前に設定されているものとする。この時のタスク
Ａ、タスクＢの動作を第11図を参照しながら説明する。
簡単のために、第11図では、デバッガの動作の図示は省
略してある。
先程と同様、２つのタスクは「ready」状態にある。デ
バッガはコマンドが入力されるまで「wait」状態であ
る。「ready」状態のタスクのうち、優先順位はタスク
Ａの方が高いため、OSはタスクＡにCPUを割当てる（第1
1図の）。タスクＡがブレークポイントに達すると、
デバッガが起動される。デバッガは、タスクＡを「wai
t」状態に遷移させる。タスクＡが「wait」状態に遷移
したことにより、OSはタスクＢにCPUを割当てる（第11
図の）。
バッガはコマンドが入力されるまで「wait」状態であ
る。「ready」状態のタスクのうち、優先順位はタスク
Ａの方が高いため、OSはタスクＡにCPUを割当てる（第1
1図の）。タスクＡがブレークポイントに達すると、
デバッガが起動される。デバッガは、タスクＡを「wai
t」状態に遷移させる。タスクＡが「wait」状態に遷移
したことにより、OSはタスクＢにCPUを割当てる（第11
図の）。
タスクＢは、I/O入出力のため「wai-sem」システムコー
ルを発行する。タスクＡはセマフォを獲得する前に「wa
it」状態に遷移したため、タスクＢはセマフォを獲得す
ることができる（第11図の）。セマフォを獲得したタ
スクＢは、I/Oとの同期をとるために「wai-tsk」システ
ムコールによって「wait」状態に入る（第11図の）。
ルを発行する。タスクＡはセマフォを獲得する前に「wa
it」状態に遷移したため、タスクＢはセマフォを獲得す
ることができる（第11図の）。セマフォを獲得したタ
スクＢは、I/Oとの同期をとるために「wai-tsk」システ
ムコールによって「wait」状態に入る（第11図の）。
この時、実行継続のため、「wait」状態に遷移していた
タスクＡは、デバッガによって「ready」状態に戻され
たとする。タスクＢは「wait」状態であるから、OSはタ
スクＡにCPUを割当てる（第11図の）。
タスクＡは、デバッガによって「ready」状態に戻され
たとする。タスクＢは「wait」状態であるから、OSはタ
スクＡにCPUを割当てる（第11図の）。
タスクＡは「wai-sem」システムコールによってセマフ
ォを獲得しようとする。しかし、すでにタスクＢがセマ
フォを獲得しているために、再び「wait」状態に遷移す
る（第11図の）。
ォを獲得しようとする。しかし、すでにタスクＢがセマ
フォを獲得しているために、再び「wait」状態に遷移す
る（第11図の）。
以上の動作説明で明らかなように、デバッグのためにタ
スクＡを停止させた（「ready」状態にした）ことによ
り、タスクＢがタスクＡよりも先に処理を行うことにな
る。本来デバッグは、対象となるシステムに対して影響
を与えてはならないものである。しかし、従来の方式で
は、タスクの同期関係、実行順序というマルチタスク処
理において最低限守らなければならないことが崩れてい
る。このために、停止させたタスクの動作を継続する
と、他のタスクによって本来獲得できるはずの資源など
がないなどの状態になり、タスクの正常な処理が行われ
なくなったりする。また、タスクＢがセマフォを獲得し
た後、タスクＡから起動されるのを待つような構成にな
っていると、タスクＡはセマフォが返却されるのを待
ち、タスクＢはセマフォを持ったままタスクＡからの起
動を待つというような状態に入ってしまう。このような
状態を「デッドロック」といい、２つのタスクは無限の
待ち状態に入ってしまう。
スクＡを停止させた（「ready」状態にした）ことによ
り、タスクＢがタスクＡよりも先に処理を行うことにな
る。本来デバッグは、対象となるシステムに対して影響
を与えてはならないものである。しかし、従来の方式で
は、タスクの同期関係、実行順序というマルチタスク処
理において最低限守らなければならないことが崩れてい
る。このために、停止させたタスクの動作を継続する
と、他のタスクによって本来獲得できるはずの資源など
がないなどの状態になり、タスクの正常な処理が行われ
なくなったりする。また、タスクＢがセマフォを獲得し
た後、タスクＡから起動されるのを待つような構成にな
っていると、タスクＡはセマフォが返却されるのを待
ち、タスクＢはセマフォを持ったままタスクＡからの起
動を待つというような状態に入ってしまう。このような
状態を「デッドロック」といい、２つのタスクは無限の
待ち状態に入ってしまう。
本発明のタスクデバッグ方式は、多重プログラミング用
オペレーティング・システム上で動作するタスクの中か
ら複数個のタスクを指定する手段と、前記指定手段によ
って指定された複数個のタスクの制御ブロック内に前記
指定手段によって指定されたことを示す情報を格納する
手段と、任意のタスクが停止させられた時に前記停止し
たタスクの制御ブロック内の情報を検査する手段と、前
記検査手段によって検査されたタスクが前記指定手段に
よって指定されていた場合、前記タスクの実行を停止さ
せる手段を具備し、前記指定手段によって指定されたタ
スクの何れかのタスクが、実行を停止された場合、他の
指定されたタスクも同時に停止されるようにしたことを
特徴とする。
オペレーティング・システム上で動作するタスクの中か
ら複数個のタスクを指定する手段と、前記指定手段によ
って指定された複数個のタスクの制御ブロック内に前記
指定手段によって指定されたことを示す情報を格納する
手段と、任意のタスクが停止させられた時に前記停止し
たタスクの制御ブロック内の情報を検査する手段と、前
記検査手段によって検査されたタスクが前記指定手段に
よって指定されていた場合、前記タスクの実行を停止さ
せる手段を具備し、前記指定手段によって指定されたタ
スクの何れかのタスクが、実行を停止された場合、他の
指定されたタスクも同時に停止されるようにしたことを
特徴とする。
次に本発明の第１の実施例について図面を参照して説明
する。タスクの数、状態、ブレークポイントの位置など
の条件は、従来例の説明で用いたものと同じとする。
する。タスクの数、状態、ブレークポイントの位置など
の条件は、従来例の説明で用いたものと同じとする。
第１図は本発明の第１の実施例を示す。第１図は、第３
図に示したタスク・コントロール・ブロックのステータ
ス領域に相当している。第１図において、識別ビットに
「１」がセットされている場合、デバッガのブレークポ
イント処理においてそのタスクを「wait」状態に遷移さ
せる。
図に示したタスク・コントロール・ブロックのステータ
ス領域に相当している。第１図において、識別ビットに
「１」がセットされている場合、デバッガのブレークポ
イント処理においてそのタスクを「wait」状態に遷移さ
せる。
「０」がセットされている場合、デバッガは何もしな
い。第６図は、この実施例において、タスクがブレーク
ポイントに達した時のデバッガの処理フローを示す。第
８図は、この実施例および後述する第２の実施例による
タスクの動作を示す。
い。第６図は、この実施例において、タスクがブレーク
ポイントに達した時のデバッガの処理フローを示す。第
８図は、この実施例および後述する第２の実施例による
タスクの動作を示す。
第５図は、各タスクのタスク・コントロール・ブロック
のリンクを示す。簡単のためにデバッガのタスク・コン
トロール・ブロックは、図示を省略してある。OSは、リ
ンクの先頭のタスクＡのタスク・コントロール・ブロッ
ク・アドレスと、リンクの最後のタスクＢのタスク・コ
ントロール・ブロック・アドレスを持っている。タスク
Ａのタスク・コントロール・ブロックには、次のタスク
・コントロール・ブロック・アドレスとして、タスクＢ
のタスク・コントロール・ブロック・アドレスを入って
いる。前のタスク・コントロール・ブロック・アドレス
は、タスクＡがリンクの先頭であるため、「０」であ
る。タスクＢのタスク・コントロール・ブロックには、
前のタスク・コントロール・ブロック・アドレスとし
て、タスクＡのタスク・コントロール・ブロック・アド
レスが入っている。次のタスク・コントロール・ブロッ
ク・アドレスは、タスクＢがリンクの最後であるため、
「０」である。
のリンクを示す。簡単のためにデバッガのタスク・コン
トロール・ブロックは、図示を省略してある。OSは、リ
ンクの先頭のタスクＡのタスク・コントロール・ブロッ
ク・アドレスと、リンクの最後のタスクＢのタスク・コ
ントロール・ブロック・アドレスを持っている。タスク
Ａのタスク・コントロール・ブロックには、次のタスク
・コントロール・ブロック・アドレスとして、タスクＢ
のタスク・コントロール・ブロック・アドレスを入って
いる。前のタスク・コントロール・ブロック・アドレス
は、タスクＡがリンクの先頭であるため、「０」であ
る。タスクＢのタスク・コントロール・ブロックには、
前のタスク・コントロール・ブロック・アドレスとし
て、タスクＡのタスク・コントロール・ブロック・アド
レスが入っている。次のタスク・コントロール・ブロッ
ク・アドレスは、タスクＢがリンクの最後であるため、
「０」である。
次に、この実施例の動作を第１図，第５図，第６図，第
８図を参照しながら説明する。
８図を参照しながら説明する。
いま、ブレークポイント到達時に停止させるグループに
タスクＡとタスクＢを指定したものとする。デバッガ
は、タスクＡとタスクＢを管理するタスク・コントロー
ル・ブロック内のステータスの識別ビットに「１」をセ
ットする。セットした後、デバッガは、「wait」状態に
遷移する。デバッガが「wait」状態に遷移したことによ
り、OSはタスクＡにCPUを割当てる（第８図の）。
タスクＡとタスクＢを指定したものとする。デバッガ
は、タスクＡとタスクＢを管理するタスク・コントロー
ル・ブロック内のステータスの識別ビットに「１」をセ
ットする。セットした後、デバッガは、「wait」状態に
遷移する。デバッガが「wait」状態に遷移したことによ
り、OSはタスクＡにCPUを割当てる（第８図の）。
タスクＡがブレークポイントに達すると、デバッガが起
動される。デバッガは、ブレークポイントで停止したタ
スクＡを「wait」状態に遷移させる。次に、タスクＡの
タスク・コントロール・ブロックは「０」であるため、
タスクＡは、リンクの先頭であることがわかる。次のタ
スク・コントロール・ブロック・アドレスは、タスクＢ
のタスク・コントロール・ブロック・アドレスである
（第６図の）。タスクＢのタスク・コントロール・ブ
ロック内の識別フラグをチェックする（第６図の）。
タスクＢの識別フラグには、上述したように予め「１」
がセットされている。したがって、デバッガはタスクＢ
を「wait」状態に遷移させる（第６図の、第８図の
）。次のタスクＢのタスク・コントロール・ブロック
を参照し、次のタスク・コントロール・ブロック・アド
レスを得る。次のタスク・コントロール・ブロック・ア
ドレスは「０」であるため、タスクＢがリンクの最後で
あることがわかる。したがって、全てのタスクのタスク
・コントロール・ブロックの参照が完了したことにな
り、ブレークポイント処理を終了する（第６図の）。
動される。デバッガは、ブレークポイントで停止したタ
スクＡを「wait」状態に遷移させる。次に、タスクＡの
タスク・コントロール・ブロックは「０」であるため、
タスクＡは、リンクの先頭であることがわかる。次のタ
スク・コントロール・ブロック・アドレスは、タスクＢ
のタスク・コントロール・ブロック・アドレスである
（第６図の）。タスクＢのタスク・コントロール・ブ
ロック内の識別フラグをチェックする（第６図の）。
タスクＢの識別フラグには、上述したように予め「１」
がセットされている。したがって、デバッガはタスクＢ
を「wait」状態に遷移させる（第６図の、第８図の
）。次のタスクＢのタスク・コントロール・ブロック
を参照し、次のタスク・コントロール・ブロック・アド
レスを得る。次のタスク・コントロール・ブロック・ア
ドレスは「０」であるため、タスクＢがリンクの最後で
あることがわかる。したがって、全てのタスクのタスク
・コントロール・ブロックの参照が完了したことにな
り、ブレークポイント処理を終了する（第６図の）。
以上の操作を行ない、デバッガは「wait」状態に入る。
３つのタスク（デバッガ、タスクＡ、タスクＢ）が共に
「wait」状態に入ったことにより、CPUはタスクが割当
てられていない状態に入る（第８図の）。ここで、実
行継続の操作が行われたとする。デバッガはブレークポ
イントに達して「wait」状態に遷移させられたタスクＡ
を、「ready」状態にする。次に、先程と同様にしてタ
スク・コントロール・ブロック内の識別フラグを検索
し、「wait」状態に遷移させられていたタスクＢを「re
ady」状態に戻す（第８図の）。デバッガは、上記の
操作を行った後「wait」状態に入る。
「wait」状態に入ったことにより、CPUはタスクが割当
てられていない状態に入る（第８図の）。ここで、実
行継続の操作が行われたとする。デバッガはブレークポ
イントに達して「wait」状態に遷移させられたタスクＡ
を、「ready」状態にする。次に、先程と同様にしてタ
スク・コントロール・ブロック内の識別フラグを検索
し、「wait」状態に遷移させられていたタスクＢを「re
ady」状態に戻す（第８図の）。デバッガは、上記の
操作を行った後「wait」状態に入る。
「ready」状態の２つのタスクのうち、タスクＡの優先
順位がタスクＢのそれよりも高いため、OSはタスクＡに
CPUを割当てる（第８図の）。
順位がタスクＢのそれよりも高いため、OSはタスクＡに
CPUを割当てる（第８図の）。
以上のようにしてタスクＡは、処理を再開する。
この実施例では、既存のタスク・コントロール・ブロッ
ク内の領域を使用することによって、テーブルのサイズ
を拡大することなく、グループ化を実現することも可能
である。
ク内の領域を使用することによって、テーブルのサイズ
を拡大することなく、グループ化を実現することも可能
である。
次に本発明の第２の実施例について図面を参照して説明
する。
する。
第２図は本発明の第２の実施例におけるタスク・コント
ロール・ブロックを示す。第７図は、この実施例におい
て、タスクがブレークポイントに達した時のデバッガの
処理フローを示す。
ロール・ブロックを示す。第７図は、この実施例におい
て、タスクがブレークポイントに達した時のデバッガの
処理フローを示す。
次に、この実施例の動作を第２図，第５図，第６図，第
８図を参照しながら説明する。タスクの数、状態などの
条件は、第１の実施例の説明で用いたものと同じとす
る。
８図を参照しながら説明する。タスクの数、状態などの
条件は、第１の実施例の説明で用いたものと同じとす
る。
いま、ブレークポイント到達時に停止させるグループに
タスクＡとタスクＢを指定したものとする。デバッガ
は、タスクＡとタスクＢを管理するタスク・コントロー
ル・ブロック内のグループIDに「１」をセットする。セ
ットした後、デバッガは、「wait」状態に遷移する。デ
バッガが「wait」状態に遷移したことにより、OSはタス
クＡにCPUを割当てる（第８図の）。
タスクＡとタスクＢを指定したものとする。デバッガ
は、タスクＡとタスクＢを管理するタスク・コントロー
ル・ブロック内のグループIDに「１」をセットする。セ
ットした後、デバッガは、「wait」状態に遷移する。デ
バッガが「wait」状態に遷移したことにより、OSはタス
クＡにCPUを割当てる（第８図の）。
タスクＡがブレークポイントに達すると、デバッガが起
動される。デバッガは、ブレークポイントで停止したタ
スクＡを「wait」状態に遷移させる。ブレークポイント
で「wait」状態にしたタスクのタスク・コントロール・
ブロックから、ブループIDを得る（第７図の）。次
に、リンク領域（次のタスクまたは前のタスクのアドレ
スが入っている領域）を参照し、タスクＢのタスク・コ
ントロール・ブロック・アドレスを得る（第７図の
）。タスクＢのタスク・コントロール・ブロックから
グループIDを得る。先に得たタスクＡのグループIDと比
較を行なう（第７図の）。上述したように、両者のグ
ループIDは、「１」である。したがって、デバッガはタ
スクＢを「wait」状態に遷移させる（第７図の、第８
図の）。デバッガは、更に次のタスク・コントロール
・ブロック・アドレスを得ようとするが、タスク・コン
トロール・ブロックは、もうリンクされていないためブ
レークポイント処理を終了する（第７図の）。
動される。デバッガは、ブレークポイントで停止したタ
スクＡを「wait」状態に遷移させる。ブレークポイント
で「wait」状態にしたタスクのタスク・コントロール・
ブロックから、ブループIDを得る（第７図の）。次
に、リンク領域（次のタスクまたは前のタスクのアドレ
スが入っている領域）を参照し、タスクＢのタスク・コ
ントロール・ブロック・アドレスを得る（第７図の
）。タスクＢのタスク・コントロール・ブロックから
グループIDを得る。先に得たタスクＡのグループIDと比
較を行なう（第７図の）。上述したように、両者のグ
ループIDは、「１」である。したがって、デバッガはタ
スクＢを「wait」状態に遷移させる（第７図の、第８
図の）。デバッガは、更に次のタスク・コントロール
・ブロック・アドレスを得ようとするが、タスク・コン
トロール・ブロックは、もうリンクされていないためブ
レークポイント処理を終了する（第７図の）。
以上の操作を行ない、デバッガは「wait」状態に入る。
３つのタスク（デバッガ、タスクＡ、タスクＢ）が共に
「wait」状態に入ったことにより、CPUはタスクが割当
てられていない状態に入る（第８図の）。ここで、実
行継続の操作が行われたとする。デバッガはブレークポ
イントに達して「wait」状態に遷移させられたタスクＡ
を、「ready」状態にする。次に、先程と同様にしてタ
スク・コントロール・ブロック内のグループIDを検索
し、「wait」状態に遷移させられていたタスクＢを「re
ady」状態に戻す（第８図の）。デバッガは、上記の
操作を行った後「wait」状態に入る。
「wait」状態に入ったことにより、CPUはタスクが割当
てられていない状態に入る（第８図の）。ここで、実
行継続の操作が行われたとする。デバッガはブレークポ
イントに達して「wait」状態に遷移させられたタスクＡ
を、「ready」状態にする。次に、先程と同様にしてタ
スク・コントロール・ブロック内のグループIDを検索
し、「wait」状態に遷移させられていたタスクＢを「re
ady」状態に戻す（第８図の）。デバッガは、上記の
操作を行った後「wait」状態に入る。
「ready」状態の２つのタスクのうち、タスクＡの優先
順位がタスクＢのそれよりも高いため、OSはタスクＡに
CPUを割当てる（第８図の）。
順位がタスクＢのそれよりも高いため、OSはタスクＡに
CPUを割当てる（第８図の）。
以上のようにしてタスクＡは、処理を再開する。
この実施例では、グループIDの領域の任意の数値をセッ
トすることによって、ブレークポイントで停止させたタ
スクのグループを複数個設定することが可能になり、そ
れぞれのブレークポイント付近で関係するタスクを細か
く指定でき、デバッグの効率を上げることができる。
トすることによって、ブレークポイントで停止させたタ
スクのグループを複数個設定することが可能になり、そ
れぞれのブレークポイント付近で関係するタスクを細か
く指定でき、デバッグの効率を上げることができる。
以上の説明から明らかなように、本発明では、ブレーク
ポイントによってあるタスクが停止した時、予め指定さ
れているブレークポイントを設定されたタスクに関係あ
るタスクを同時に停止できる。このことにより、従来の
方式では不可能だったタスクの同期関係を維持すること
が可能となり、ブレークポイントで停止したタスクを再
開した場合、それ以降の処理も正常に行われるという効
果が奏される。
ポイントによってあるタスクが停止した時、予め指定さ
れているブレークポイントを設定されたタスクに関係あ
るタスクを同時に停止できる。このことにより、従来の
方式では不可能だったタスクの同期関係を維持すること
が可能となり、ブレークポイントで停止したタスクを再
開した場合、それ以降の処理も正常に行われるという効
果が奏される。
更に本発明によれば、タスク間の同期関係を維持するた
めにシステム全体を停止させる方式と異なり、ブレーク
ポイントを設定したタスクの処理と全く関係ない処理を
行っているタスクに影響を与えることがない。
めにシステム全体を停止させる方式と異なり、ブレーク
ポイントを設定したタスクの処理と全く関係ない処理を
行っているタスクに影響を与えることがない。
第１図は本発明の第１の実施例を示す図、第２図は本発
明の第２の実施例を示す図、第３図はタスク・コントロ
ール・ブロックの構造を例示する図、第４図はタスク・
コントロール・ブロック間のリンクの一般例を示す図、
第５図はタスクが２つの場合のリンク関係を示す図、第
６図は第１の実施例においてタスクがブレークポイント
に達した場合のデバッガの処理を示すフロー図、第７図
は第２の実施例においてタスクがブレークポイントに達
した場合のデバッガの処理を示すフロー図、第８図は本
発明の実施例におけるタスクの動作を例示する図、第９
図はOS上のタスクの状態遷移を示す図、第10図は通常の
場合の２タスクの動作を例示する図、第11図は従来例に
おける２タスクの動作を例示する図である。 0,・・・,14,15……ビット位置。
明の第２の実施例を示す図、第３図はタスク・コントロ
ール・ブロックの構造を例示する図、第４図はタスク・
コントロール・ブロック間のリンクの一般例を示す図、
第５図はタスクが２つの場合のリンク関係を示す図、第
６図は第１の実施例においてタスクがブレークポイント
に達した場合のデバッガの処理を示すフロー図、第７図
は第２の実施例においてタスクがブレークポイントに達
した場合のデバッガの処理を示すフロー図、第８図は本
発明の実施例におけるタスクの動作を例示する図、第９
図はOS上のタスクの状態遷移を示す図、第10図は通常の
場合の２タスクの動作を例示する図、第11図は従来例に
おける２タスクの動作を例示する図である。 0,・・・,14,15……ビット位置。
Claims (1)
- 【請求項１】多重プログラミング用オペレーティング・
システム上で動作するタスクの中から複数個のタスクを
指定する手段と、前記指定手段によって指定された複数
個のタスクの制御ブロック内に前記指定手段によって指
定されたことを示す情報を格納する手段と、任意のタス
クが停止させられた時に前記停止したタスクの制御ブロ
ック内の情報を検査する手段と、前記検査手段によって
検査されたタスクが前記指定手段によって指定されてい
た場合、前記タスクの実行を停止させる手段を具備し、
前記指定手段によって指定されたタスクの何れかのタス
クが、実行を停止された場合、他の指定されたタスクも
同時に停止されるようにしたことを特徴とするタスクデ
バッグ方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1123712A JPH07120302B2 (ja) | 1989-05-16 | 1989-05-16 | タスクデバッグ方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1123712A JPH07120302B2 (ja) | 1989-05-16 | 1989-05-16 | タスクデバッグ方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH02300942A JPH02300942A (ja) | 1990-12-13 |
| JPH07120302B2 true JPH07120302B2 (ja) | 1995-12-20 |
Family
ID=14867492
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP1123712A Expired - Fee Related JPH07120302B2 (ja) | 1989-05-16 | 1989-05-16 | タスクデバッグ方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH07120302B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5632032A (en) * | 1994-02-07 | 1997-05-20 | International Business Machines Corporation | Cross address space thread control in a multithreaded environment |
| JP3571976B2 (ja) | 1999-11-08 | 2004-09-29 | 富士通株式会社 | デバッグ装置及び方法並びにプログラム記録媒体 |
| JP3558052B2 (ja) * | 2000-06-02 | 2004-08-25 | ヤマハ株式会社 | マルチメディア実行システム、マルチメディアファイルの実行方法およびシーケンサにより読み出し可能なマルチメディアファイル構造体 |
-
1989
- 1989-05-16 JP JP1123712A patent/JPH07120302B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH02300942A (ja) | 1990-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10990513B2 (en) | Deterministic concurrent test program executor for an automated test equipment | |
| US5632032A (en) | Cross address space thread control in a multithreaded environment | |
| US10481911B2 (en) | Synchronization of execution threads on a multi-threaded processor | |
| US3614745A (en) | Apparatus and method in a multiple operand stream computing system for identifying the specification of multitasks situations and controlling the execution thereof | |
| CN101556545B (zh) | 一种实现进程支持的方法、装置和多线程系统 | |
| WO2017166777A1 (zh) | 一种任务调度方法及装置 | |
| JP2001134466A (ja) | デバッグ装置及び方法並びにプログラム記録媒体 | |
| JPH0644235B2 (ja) | コンピュータ・システムを操作する方法 | |
| US8225320B2 (en) | Processing data using continuous processing task and binary routine | |
| JPH1153202A (ja) | 並列トランザクション処理システム | |
| JP2000066904A (ja) | マルチタスク制御方法及び記憶媒体 | |
| US11106395B2 (en) | Application execution apparatus and application execution method | |
| CN112363816B (zh) | 嵌入式多核操作系统确定性调度方法、系统及介质 | |
| JPH07120302B2 (ja) | タスクデバッグ方式 | |
| JPH07120301B2 (ja) | タスクデバッグ方法 | |
| CN117743176A (zh) | 需求测试方法、装置、存储介质及计算机设备 | |
| CN120723417B (zh) | 基于分布式架构的异构数据库迁移调度方法、设备及装置 | |
| CN115599525A (zh) | 一种异步任务的调度方法、装置、设备及存储介质 | |
| JPH10111857A (ja) | マルチプロセッサ | |
| CN118277067B (zh) | 轮询器管理方法、设备、介质及计算机程序产品 | |
| JPH11306149A (ja) | 並列演算処理装置およびその方法 | |
| CN117687805B (zh) | 一种应用于plc与装置的多线程数据同步方法及系统 | |
| CN115203119B (zh) | 一种多核soc同步系统 | |
| JP2000305751A (ja) | 並列ソート装置及び該装置のプログラムを記録した記録媒体 | |
| CN120144255A (zh) | 一种多任务调度方法和plc控制器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |