(57)【要約】【課題】本発明はタスク間通信の効率化方法に関し、イベントが連続して入ってくる場合においてもマルチタスク装置の負荷を軽減することができ、イベント送信時のシーケンス逆転も発生しないタスク間通信の効率化方法を提供することを目的としている。【解決手段】イベントを受信する受信部と、イベントを処理するタスク部と、タスク部により処理された結果を送信する送信部よりなるマルチタスク装置において、  複数のイベントを受信した時、これら複数のイベントを一つの送信キューにまとめ、タスク部に渡すように構成する。【選択図】図５
2008071106.tif 000002
【特許請求の範囲】
【請求項１】
イベントを受信する受信部と、イベントを処理するタスク部と、タスク部により処理された結果を送信する送信部よりなるマルチタスク装置において、
複数のイベントを受信した時、これら複数のイベントを一つの送信キューにまとめ、タスク部に渡すように構成することを特徴とするタスク間通信の効率化方法。
【請求項２】
各タスクで送信するイベントを管理するイベントキュー管理テーブルを設け、タスク毎のイベントキューイングを実施することを特徴とする請求項１記載のタスク間通信の効率化方法。
【請求項３】
前記イベントキュー管理テーブルから各タスクへ起動する契機は、
１）定義されたキューイング数を超えた場合
２）一定時間が経過した場合
３）入力されてきたイベントが全てイベントキュー管理テーブルに接続された場合
のいずれかであることを特徴とする請求項２記載のタスク間通信の効率化方法。
【請求項４】
発生するイベントに対して、イベント受信時にイベント毎にブロック番号とシーケンス番号の付与を行ない、これらをブロック番号管理テーブルで管理し、イベント発生順にタスク処理結果を送信するようにしたことを特徴とする請求項１記載のタスク間通信の効率化方法。
【請求項５】
受信したイベントに対して受信キュー内でソート処理を行ない、優先度の高いイベントから送信するようにしたことを特徴とする請求項１記載のタスク間通信の効率化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はタスク間通信の効率化方法に関する。
【背景技術】
【０００２】
イベントの受信部、受信部からのイベントを処理するタスク部及びタスク部からの結果を送信する送信部よりなるマルチタスク装置が知られている。図１４はマルチタスク装置の構成例を示す図である。マルチタスク装置１０は、イベントを受信する受信部１と、該受信部１からのイベントを処理するタスク部２と、該タスク部２で処理された結果を送信する送信部３より構成されている。タスク部２には、図に示すように複数のタスクａ、タスクｂ、タスクｃ…から構成されている。この装置では、イベントを受信する度にタスク起動を行ない、処理を行なうようになっている。
【０００３】
従来のこの種の装置としては、イベント情報に関する事象キュー要素をＦＩＦＯ方式で順次登録／取り出しするものであって、事象キュー要素のキューイング処理及びキューアウト処理を各々別々に実行するマルチタスクを備えたシステムが知られている（例えば特許文献１参照）。また、タスク管理部は逐次実行初期化部で、逐次処理要求キューを生成し、タスク識別子テーブルを参照して、当該キューにタスク識別子を起動順に登録する技術が知られている（例えば特許文献２参照）。また、必要なリソース毎にタスクのキューをグルーピングしそれぞれのグルーピングされたレディキュー毎に管理しているポインタによりタスクの選択を行なう技術が知られている（例えば特許文献３参照）。
【特許文献１】特開平１１−１８４７１６号公報（段落０００８〜００１４、図１〜図５）
【特許文献２】特開平１０−２９３６９３号公報（段落００２２〜００４３、図１）
【特許文献３】特開平６−１３９０８３号公報（段落０００８〜０００９、図１〜図３）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
図１４に示す従来装置の場合、連続的にイベントが発生した場合には、イベント単位でタスクを起動する。これにより、タスク起動がオーバヘッドとなり処理性能を落としていた。また、イベントが連続的に発生する状態では、装置が輻輳状態に陥り、リソース不足が発生する危険がある。
【０００５】
例えば、図１４で示した装置が０／１構成で動作しており、イベント発生源１１から均等にイベントが発行されている状態で、装置０が故障し、イベントが装置１に集中した場合に装置１では大量のイベントを連続的に受信することになる。図１５はイベント連続受信発生説明図である。図１４と同一のものは、同一の符号を付して示す。（ａ）は装置０と装置１とがイベント発生源１１からの平均的なイベント発行をそれぞれ受信して均等に動作している場合を示している。
【０００６】
ここで、（ｂ）に示すように装置０で故障が発生したものとする。この故障発生は、イベント発生源１１に通知される。そこで、イベント発生源１１は全てのイベントを装置１に対して発行することになる。この結果、装置１は過負荷状態でしまいにはダウンするおそれがある。図１５では、装置１で発生する一つ一つのイベント毎にタスクを起動するが、タスクを起動するにはリソースを必要とするため、連続的にイベントを受信すると大量のリソースを必要とするという問題がある。
【０００７】
図１６は従来のタスク起動の説明図である。連続的にイベントＡ〜イベントＤを受信したものとする。これらイベントは、受信部１に入り、送信キューで待たされる。そして、送信キュー毎のイベントをタスクａに渡すようになっている。それぞれのイベント毎にタスク起動が行われていることが分かる。
【０００８】
また、従来のこの種の装置の場合、複数のイベントが同時に各タスクを経由することで、タスク毎のプライオリティの関係から送信時のシーケンスが受信時のシーケンスと異なるケースも出てくる。図１７は内部処理によるシーケンス逆転の説明図である。受信時にはイベントＡ，イベントＢ，イベントＣという順序で入ってくるが、タスク内の処理により順番が逆転し、イベントＢ，イベントＡ，イベントＣの順に送信される場合がある。図はラウンドロビン方式を使用した場合に発生する。ここで、ラウンドロビンとは、一定時間毎にタスクを起動させることをいう。起動したタスクは、タイムスライスの時間実行される。そして、完了後に次のタスクを起動するようになっている。
【０００９】
本発明はこのような課題に鑑みてなされたものであって、イベントが連続して入ってくる場合においてもマルチタスク装置の負荷を軽減することができ、イベント送信時のシーケンス逆転も発生しないタスク間通信の効率化方法を提供することを目的としている。
【課題を解決するための手段】
【００１０】
（１）請求項１記載の発明は、イベントを受信する受信部と、イベントを処理するタスク部と、タスク部により処理された結果を送信する送信部よりなるマルチタスク装置において、複数のイベントを受信した時、これら複数のイベントを一つの送信キューにまとめ、タスク部に渡すように構成することを特徴とする。
（２）請求項２記載の発明は、各タスクで送信するイベントを管理するイベントキュー管理テーブルを設け、タスク毎のイベントキューイングを実施することを特徴とする。
（３）請求項３記載の発明は、前記イベントキュー管理テーブルから各タスクへ起動する契機は、
１）定義されたキューイング数を超えた場合
２）一定時間が経過した場合
３）入力されてきたイベントが全てイベントキュー管理テーブルに接続された場合
のいずれかであることを特徴とする。
（４）請求項４記載の発明は、発生するイベントに対して、イベント受信時にイベント毎にブロック番号とシーケンス番号の付与を行ない、これらをブロック番号管理テーブルで管理し、イベント発生順にタスク処理結果を送信するようにしたことを特徴とする。
（５）請求項５記載の発明は、受信したイベントに対して受信キュー内でソート処理を行ない、優先度の高いイベントから送信するようにしたことを特徴とする。
【発明の効果】
【００１１】
（１）請求項１記載の発明によれば、複数のイベントを一つの送信キューにまとめるので、タスク起動を複数のイベントを一つの送信キューにまとめたものに対して行えばすむので、マルチタスク装置の負荷を軽減することができる。
（２）請求項２記載の発明によれば、イベントキュー管理テーブルを用いることにより、タスク毎のイベントキューイングを効率よく行なうことができる。
（３）請求項３記載の発明によれば、イベントキュー管理テーブルから各タスクへ起動するタイミングとして前記した３種類の内の何れかを契機とすることにより、タスク起動を効率よく行なうことができる。
（４）請求項４記載の発明によれば、イベントをブロック番号とシーケンス番号とで管理することにより、イベント発生順にタスク処理結果を送信することができる。
（５）請求項５記載の発明によれば、受信キュー内でソート処理を行ない、優先度の高いイベントから送信するようにすることができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図１はイベント結合の説明図であり、本発明の概念図である。図に示すようにイベントがＡ〜Ｄと連続して受信された場合、受信部１５では、一つの送信キューにまとめる。そして、送信キューからタスクａの起動を行なう。このようにすることで、イベント毎に起動していたタスク起動が１回ですむので処理時間を短縮することができる。図２は従来例と本発明の処理時間の比較説明図である。従来の場合、図に示すようにそれぞれのイベントの受信毎にタスク起動を行なっている。これに対して、本発明では先ず全てのイベントの受信を行なった後にタスク起動を行なっている。従って、処理が終了するまでの時間に従来の場合と本発明の場合とで差がでる。図のΔｔが短縮された時間である。このように、本発明によれば、複数のイベントを一つの送信キューにまとめるので、タスク起動を複数のイベントを一つの送信キューにまとめたものに対して行えばすむので、マルチタスク装置の負荷を軽減することができる。
【００１３】
図３は送信順序制御によるシーケンス正常化の説明図である。イベントＡ〜Ｃが受信されたものとする。処理部１６は入力されたイベントに識別子を付与する。例えば、イベントＡに０１、イベントＢに０２、イベントＣに０３という具合に識別子を付与する。処理部１６だタスクの内部処理を行なった結果、順序が逆転したものとする。例えば、イベントＢがイベントＡよりも速く処理が終了したとする。この場合、イベントＢが先ず送信され、次にイベントＡが送信され、次にイベントＣが送信されることになる。ここで、処理部１６では、最初に処理が終了したイベントの識別子が０２であったものとすると、識別子が一番若い０１がまだ終了していないことを認識する。そして、０１が終了したことを認識したら、送信時に識別子の順序でイベントを送信するものとする。この結果、イベントＡ、イベントＢ、イベントＣの順序で送信される。
【００１４】
次に、本発明の具体的実施の形態例について説明する。図４はイベントキュー管理テーブルの説明図である。図において、１７がイベントキュー管理テーブルである。イベントキュー管理テーブル１７はタスク毎に分かれており、それぞれのタスクで起動されるイベントの集団が割り当てられる。即ち、イベントキュー管理テーブル１７で、タスク毎に分類してキューイングする。例えば、イベントＡ〜イベントＣはタスクＡに起動されるイベントの集団であり、イベントＤ、イベントＥはタスクｃに起動されるイベントの集団である。このようにすれば、イベントキュー管理テーブルを用いることにより、タスク毎のイベントキューイングを効率よく行なうことができる。
【００１５】
ここで、イベントキュー管理テーブルから各タスクへ起動する契機は以下の３通りとする。
１）定義されたキューイング数を超えた場合
２）一定時間が経過した場合
３）入力されてきたイベントが全てキューイング管理テーブルに接続された場合
このように各タスクへ起動する契機を定めることで、タスク起動を効率よく行なうことができる。
【００１６】
なお、ここで、各タスクへ起動する順番は、タスクのプライオリティに依存するようにする。例えば、図４において、各タスクのプライオリティがタスクａ＞タスクｂ＞タスクｃ＞タスクｄとなっていた場合には、タスクａ→タスクｂ→タスクｃ→タスクｄの順番に起動処理を実施する。このようにすれば、受信キュー内でソート処理を行ない、優先度の高いイベントから送信するようにすることができる。
【００１７】
次に、イベントの順序制御について説明する。発生するイベントの順序制御を実施することにより、外部装置に対してのイベント発生順での応答を保証することが可能となる。そこで、イベントを受信する毎にブロック番号とシーケンス番号の付与を行ない、それを識別子として制御を行なう。ここで、ブロック番号とは、連続して処理するイベントのグループ番号である。ブロック番号は緊急と通常に分かれており、処理の中で緊急と通常は変更することが可能であるものとする。シーケンス番号は、イベントグループ内のシーケンス番号である。
【００１８】
本発明によれば、ブロック番号とシーケンス番号の管理は、ブロック番号管理テーブルで実施する。ブロック番号管理テーブルでは、ブロック番号の使用状況と最新ブロック番号の管理、シーケンス番号の使用状況を管理する。
【００１９】
図５は識別子付与の説明図である。イベントＡ〜イベントＤが受信部１５に入力される。受信部１５では、ブロック番号管理テーブル１８を参照して、ブロック番号とシーケンス番号とを取得してキューイングする。ブロック番号管理テーブル１８は、グループを示すブロック番号とシーケンス番号の管理を行なう。図に示す例の場合、イベントに対してグループを示す“０２”とシーケンスを示す“０１”〜“０４”が付与される。即ち、イベントＡにはブロック番号“０２”とシーケンス番号“０１”が付与される。イベントＢにはブロック番号“０２”とシーケンス番号“０２”が、イベントＣにはブロック番号“０２”とシーケンス番号“０３”が、イベントＤにはブロック番号“０２”とシーケンス番号“０４”が付与される。ブロック番号とシーケンス番号とが付与されたイベントは、送信キューでグループ化された後、送信キューに渡される。このようにすれば、イベントをブロック番号とシーケンス番号とで管理することにより、イベント発生順にタスク処理結果を送信することができる。
【００２０】
以下、本発明の動作説明を行なう。図６はタスク間通信（受信部）の説明図である。先ず、受信部１５ではイベントを連続して受信する（１））。ここで、受信されるイベントはイベントＡ〜イベントＤであるものとする。受信部１５では、受信した各イベントにブロック番号とシーケンス番号とを付与する（２））。例えば、イベントＡは０２−０１、イベントＢは０２−０２、イベントＣは０２−０３、イベントＤは０２−０４である。ブロック番号とシーケンス番号とが付与されたら、送信キューにイベントを接続する（３））。次に、送信キューはタスクａに渡される（４））。この結果、タスクａが起動される。
【００２１】
図７はタスク間通信（タスク起動）の説明図である。図では、タスクａ処理の後にタスクｂ処理を行なう場合について示している。前記ステップ４）で渡されたキューを受信キューとする（５））。この結果、受信キューにはイベントＡ〜イベントＤが接続される。そして、受信キューの先頭（ここではイベントＡ）からイベント処理を実施する（６））。処理が完了したイベントはキュー管理部１９（タスクａ用）上の次起動タスクキューに接続する（７））。この結果、キュー管理部１９には、タスクｂにイベントＡとイベントＢが接続され、タスクｄにイベントＣとイベントＤとが接続される。そして、ステップ６）から７）を、受信キューに接続されているイベント数分、若しくは一定時間繰り返す（８））。そして、受信キューの接続数が０、若しくは一定時間経過したらキュー管理部１９に接続されているイベントをプライオリティの高いタスクの次起動タスクキューから次タスク（タスクｂ）へタスクａの次起動タスクキューを渡す（９））。この場合、以下の条件のどれかが一致したら次タスクを起動する。
１）最大キューイング数超過
２）一定時間経過
３）受信キューのイベント処理完了
そして、ステップ９）で渡されたキューをタスクｂの受信キューとする（１０））。次に、タスクｂで６）〜９）と同様の動作を行なう（１１））。
【００２２】
図８はタスク間通信（送信部）の説明図である。送信部２０では、ステップ１１）で渡されたキューを受信キューとする（１２））。送信部２０では、受信キュー内部でソート処理を行ない、優先度の高いイベントから送信する（１３））。そして、送信処理を行なう（１４））。なお、ブロック番号で緊急の番号を予め用意しておくことで、最優先で処理をしなければならない処理を優先的に処理することが可能である。図８に示す例では、イベントＥ、イベントＢ、イベントＡ、イベントＣと受信したイベントを送信する場合には、イベントＡ、イベントＢ、イベントＣ、イベントＥの順で送信する。
【００２３】
図９はイベント受信からタスク起動までのシーケンスを示す図である。受信部でイベントＡ〜イベントＣを受信する（Ｓ１）。キュー管理部１９にはイベントＡ、イベントＢ、イベントＣの順でキュー管理部１９に接続される。この場合において、キュー管理部１９は、キューイング時にシーケンシャルに番号を付与する（Ｓ２）。そして、受信キューにイベントＡ、イベントＢ、イベントＣが接続される。そして、イベントＡ、イベントＢ、イベントＣを同時に渡し、タスクａを起動する（Ｓ３）。
【００２４】
タスクａでは、先ずイベントＡ処理を行ない（Ｓ４）、次にイベントＢ処理を行ない（Ｓ５）、次にイベントＣ処理を行なう（Ｓ６）。イベント処理の結果、キュー管理部１９のタスクｂにはイベントＡとイベントＣが、タスクｃにはイベントＢが接続される。この場合において、一定時間経過後、もしくは受信イベント処理が完了するとタスクを起動する。そして、タスク起動の順番は、タスクプライオリティ順に起動する。
【００２５】
タスクａの処理結果に基づいて、タスクｂが起動され（Ｓ７）、タスクｃが起動される（Ｓ８）。タスクｂではイベントＡとイベントＣの処理を行なう。タスクｃではイベントＢの処理を行なう。
【００２６】
図１０は受信処理動作を示すフローチャートである。先ず、イベント受信状態を取得する（Ｓ１）。そして、イベントがあるかどうかチェックする（Ｓ２）。イベントがある場合には、ブロック番号、シーケンス番号の付与を行ない（Ｓ３）、受信キューにキューイングする（Ｓ４）。ステップＳ２でイベントがない場合には、ステップＳ５にスキップする。ステップＳ１からＳ４までを必要なだけ繰り返したら、タスク起動処理を行なう（Ｓ５）。
【００２７】
図１１はタスク処理動作を示すフローチャートである。先ず、タイマ処理を起動する（Ｓ１）。次に、受信キューよりイベントを取得する（Ｓ２）。そして、イベントがあるかどうかチェックする（Ｓ３）。イベントがある場合には、タスク処理を実施し（Ｓ４）、キュー管理テーブルにイベントを接続する（Ｓ５）。ステップＳ３でイベントがない場合にはステップＳ６にスキップする。ステップＳ２からＳ５までを必要なだけ繰り返したら、タスク起動処理を行なう（Ｓ６）。
【００２８】
図１２はタイマＴ．Ｏ処理動作を示す図である。タイマＴ．Ｏ起動処理動作は、タスク起動処理を行なうことで実現される。図１３は送信処理動作を示すフローチャートである。先ずイベント受信状態を取得する（Ｓ１）。そして、イベントがあるかどうかチェックする（Ｓ２）。イベントがある場合には、ブロック番号、シーケンス番号から送信入れ替えを行ない（Ｓ３）、送信キューにキューイングする（Ｓ４）。ステップＳ２において、イベントがない場合には、ステップＳ５にスキップする。そして、ステップＳ１とＳ４を必要なだけ繰り返したら、イベント送信処理を行なう（Ｓ５）。
【図面の簡単な説明】
【００２９】
【図１】イベント結合の説明図である。
【図２】従来例と本発明の処理時間の比較説明図である。
【図３】送信順序制御によるシーケンス正常化の説明図である。
【図４】イベントキュー管理テーブルの説明図である。
【図５】識別子の付与の説明図である。
【図６】タスク間通信（受信部）の説明図である。
【図７】タスク間通信（タスク起動）の説明図である。
【図８】タスク間通信（送信部）の説明図である。
【図９】イベント受信からタスク起動までのシーケンスを示す図である。
【図１０】受信処理動作を示すフローチャートである。
【図１１】タスク処理動作を示すフローチャートである。
【図１２】タイマＴ．Ｏ処理動作を示すフローチャートである。
【図１３】送信処理動作を示すフローチャートである。
【図１４】マルチタスク装置の構成例を示す図である。
【図１５】イベント連続受信発生の説明図である。
【図１６】従来のタスク起動の説明図である。
【図１７】内部処理によるシーケンス逆転の説明図である。
【符号の説明】
【００３０】
１５  受信部
１６  処理部
１７  イベントキュー管理テーブル
１８  ブロック番号管理テーブル
１９  キュー管理部
２０  送信部
【図１】
2008071106.tif 000003
【図２】
2008071106.tif 000004
【図３】
2008071106.tif 000005
【図４】
2008071106.tif 000006
【図５】
2008071106.tif 000007
【図６】
2008071106.tif 000008
【図７】
2008071106.tif 000009
【図８】
2008071106.tif 000010
【図９】
2008071106.tif 000011
【図１０】
2008071106.tif 000012
【図１１】
2008071106.tif 000013
【図１２】
2008071106.tif 000014
【図１３】
2008071106.tif 000015
【図１４】
2008071106.tif 000016
【図１５】
2008071106.tif 000017
【図１６】
2008071106.tif 000018
【図１７】
2008071106.tif 000019