(57)【要約】【課題】シングルコア・アプリケーションをタスク分割して複数コアに振り分ける場合、複数コア間のタスクが特定条件下で連携して起床できるような、スケジューリングメカニズムを提供する。【解決手段】プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を、自タスクのタスクコントロールブロックに格納し、該情報を用いて自コアから他コアＯＳ配下のデータ構造を直接操作する。【選択図】図２
2018049406.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納することを特徴とする複数プロセッサ間のタスク連携装置。
【請求項２】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納し、該格納された情報には他コアＯＳ管理下のタスクコントロールブロックの位置情報やレディーキューの位置情報を含むことを特徴とする請求項１記載の複数プロセッサ間のタスク連携装置。
【請求項３】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納し、該格納された情報が指し示すデータ構造は、自プロセッサと他プロセッサ両方からアクセス可能な共有メモリ上に配置されることを特徴とする請求項１記載の複数プロセッサ間のタスク連携装置。
【請求項４】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納するとともに、自タスクが何回起床後に他コアに属するタスクが連携して起床されるかの条件およびそれを計数するカウンタに関する情報も自タスクのタスクコントロールブロックに格納することを特徴とする請求項１記載の複数プロセッサ間のタスク連携装置。
【請求項５】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納し、該情報を用いて他コアに属する連携タスクを起床する動作は、自タスク所属のＯＳがスピンロック機構を通じて他コアＯＳ管理下の資源を排他的に操作することで実現することを特徴とする請求項１記載の複数プロセッサ間のタスク連携装置。
【請求項６】
プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳにおいて、自タスクと連携して起床する他コアに属するタスクの情報を自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納し、該格納される情報はＯＳの実装コード翻訳時（ＯＳコンフィギュレーション時）に静的に生成され装置に格納されることを特徴とする請求項１記載の複数プロセッサ間のタスク連携装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数プロセッサを用いた車載制御装置およびその制御ソフトウェアに関する。
【背景技術】
【０００２】
高性能化への要求に応えるため、組込みシステムではこれまでＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）のクロック周波数を高めることで処理能力の向上を図ってきた。しかしその結果、消費電力／発熱量／ノイズなどが増加するという問題が発生している。こうした課題を解決する技術として近年注目されているのが、チップ内にＣＰＵコアを複数実装して各コアの負荷を減少させる「マルチコア」システムである。
【０００３】
しかしながら、マルチコアに対応したすべての機能（処理）を一から開発するのではコストが掛かり過ぎてしまう。やはり現実的にはシングルコアで動作していた既存資産を流用した開発が望まれる。つまり既存資産である逐次処理を処理分散させた並列化処理に変更する必要があり、その手法や元になる技術の確立が望まれている。
【０００４】
ここでそれまでシングルコアで動いていた処理要素（タスク）を複数コアに分散させるには、二点、技術的に大きな課題がある。先ず第一点目は、複数コアを跨いでの全体的なスケジューリング制御の問題である。次に二点目として、コア間での共有メモリを介したデータフロー、すなわち情報のやり取りの問題である。
【０００５】
今までのシングルコアでは、タスク優先度の差による排他制御、もしくは割り込み禁止による絶対的な無中断制御の形で、競合リソースに対する排他制御が実装されていた。
【０００６】
この競合リソースをタスクの時間的な順序制約と解釈すれば、前述の複数コアでのスケジューリング問題に相当し、それとは別に、データをやり取りするメモリのデータセット（同時性を確保すべき所定データの組）の健全性と解釈すれば、前述の共有メモリの問題に相当するのであって、これらは元々シングルコアの場合は、前述のタスク優先度と割り込み禁止メカニズムによって暗黙的に解消されていたものである。
【０００７】
シングルコアの処理を複数コアにタスク分散させた場合、互いのコアはそのままでは無同期にてんでバラバラに動作している状態であって、タスク優先度や割り込み禁止メカニズムはあくまでローカルコア内だけの制約にとどまる。したがって、上記二点の課題を解消してシングルコアで実装していた制御の等価性を複数コアの形態にまで踏襲させなければならない。
【０００８】
そのためには新たな技術開発が必要となるのは、以上述べた理由による。
【０００９】
従来技術における上記の技術開発に関連した先行発明では、まず分散制御アプリケーションの位置独立による再利用性を向上させた制御ソフトウェア構造（分散制御プラットフォーム）に関する技術（特許文献１）、次に分散制御と複数コア制御でのデータ授受インターフェースを統一化させた技術（特許文献２）が知られている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００４−２２０３２６号公報
【特許文献２】特開２０１０−６１３２４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記特許文献１では、各制御アプリケーションよりデータ管理機能および時間同期機能を抽出し、替わって各ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）や制御ノードに共通な分散制御アプリケーションフレームワーク中に該機能を移管することにより各制御アプリケーションの実装位置独立性を高めるものである。
【００１２】
この特許文献１は、Ｎノード分散制御アプリケーションのシステム変更（ノード数の変更や特定アプリケーションを搭載するノードの変更）における既存アプリケーションの流通を意図した発明である。
【００１３】
この特許文献１には、マルチコアという文言はことさら出て来ないが、マルチコアに対して拡大解釈すれば、Ｎノード分散制御アプリケーションとＮコア・アプリケーションとの間の相互変換を図る発明でもある。
【００１４】
しかしながら、上記背景技術で言及した近年のマルチコアに対するニーズ、すなわちシングルコアからＮコアへの既存ソフトの変換をサポートするものでは無い。また、マルチコアＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）に関連した前述の二点の課題についてこれを解決する発明でも無い。
【００１５】
上記特許文献２では、Ｎノード分散制御アプリケーションで用いるネットワーク通信を介してデータの読み書きを行う処理ソフトウェアと、Ｎコア・アプリケーションで用いる共有メモリを介してデータの読み書きを行う処理ソフトウェアとのインターフェースを相互に共通化する。
【００１６】
これにより、Ｎノード分散制御アプリケーションとＮコア・アプリケーションとのソフトウェアの相互形態変換や流通を促進するものである。
【００１７】
しかしながら、データフローに関してのみ前述の共有メモリについての問題を解決する発明であり、スケジューリングの等価性に関しては依然未解決である。
【００１８】
また、発明の視点がシングルコアからＮコアへの既存ソフトの変換のサポートではないので、共有メモリを介してのやり取りが、そもそも共有メモリを持たないシングルコアの状態からマルチコア移行に伴い、移行手法をどうするのかとか、どれだけスループット低下が発生するのかの評価や検討に欠けるという欠点もある。
【００１９】
本発明は、上記複数の先行特許文献で未解決であったシングルコアからＮコアへの既存ソフトの変換のサポート技術、特に複数コアでのタスクの連携スケジューリング問題を解決するためになされたものである。
【課題を解決するための手段】
【００２０】
本発明に係る複数プロセッサ間のタスク連携装置においては、プロセッサ・コア毎にレディーキューを有する機能分散型マルチプロセッサＯＳのデータ構造に関して、自タスクと連携して起床する他コアに属するタスクの情報を、自タスクのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に格納する。
【発明の効果】
【００２１】
本発明に係る複数プロセッサ間のタスク連携装置によれば、自タスクの起床履歴に連動して起床すべき他ＯＳの他タスクを、自ＯＳが自タスクのタスクコントロールブロックの情報により（他ＯＳの関与無しに）直接操作して起床することができる。
【００２２】
したがって、前述したシングルコアからＮコアへの既存ソフトの変換で問題となるタスクのＯＳを跨いでの連携動作を実装することができる。
【００２３】
この複数ＯＳ間のタスク連携は、アプリケーションレベルで何らかのＯＳのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を操作することによって実装されてはいないので、アプリケーションコードにこれらの指示命令が混入することが無い。したがってアプリケーションプログラマはこれらの実装知識や責任から解放されるので、アプリケーションプログラム自体の独立性が高まり、流通を見越した該プログラムの部品化に寄与する効果が有る。
【００２４】
また、タスクコントロールブロックの情報は、ＯＳのコンフィギュレーション時に静的に翻訳されコードとして格納されるので、タスクから動的にＡＰＩを発行することと異なり高速で実行することができるという効果が有る。
【図面の簡単な説明】
【００２５】
【図１】実施形態に係る複数プロセッサ間のタスク連携装置のハードウェア的な全体構成図である。
【図２】実施形態に係る複数プロセッサ間のタスク連携装置のソフトウェア的な機能概念図である。
【図３】シングルコアからマルチコアへのタスク振り分けを行う変換技術の概念図である。
【図４】複数コアの各々で独立して実行されているＯＳの状態遷移と関連キューの動作を示す図である。
【図５】実施形態に係る該当ＯＳのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）を例示する図である。
【図６】実施形態に係る自ＯＳから他ＯＳに所属するタスクを直接起床する（直接操作法による）手続きを示す概念図である。
【図７】実施形態に係る自ＯＳから他ＯＳに所属するタスクを直接起床する（直接操作法による）手続きを示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下本発明の実施形態の一例について説明する。
【００２７】
図1は、本発明の実施例におけるハードウェアの全体的構成図を示したものである。
図では、ＭＰＵ（Ｍｉｃｒｏ−ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）チップ１００の中に、二つのＣＰＵ、ＣＰＵ１（１０１）ＣＰＵ２（１０２）が格納されている。しかしながら、２つに限ること無く複数個（Ｎ個）格納されていても本発明は適用可能である。
【００２８】
ここでは、基本的な動作を解説する上で便宜上ＣＰＵ２個の相互連携を考えれば事足りるので２個で解説を行うが、本発明をもっと多数のＮ個に拡張してもよいことは前述のとおりである。
【００２９】
ＣＰＵ１（１０１）とＣＰＵ２（１０２）は共通バス１０３と接続している。また共通バス１０３はその他に共有ＲＡＭ１０４、共有ＲＯＭ１０５、Ｉ／Ｏデバイス１０６、割り込みコントローラ１０７とも接続が図られている。
【００３０】
ＣＰＵ１（１０１）とＣＰＵ２（１０２）は、上記共通バス１０３を介してこれら１０４〜１０７のデバイスを直接読み書き可能であるが、ＣＰＵ１（１０１）とＣＰＵ２（１０２）が同時にアクセスした場合、ハードウェア的な競合が発生しないように共通バス１０３にはハードウェア的な調停の仕組みが格納されている。実際には競合が発生した場合、待機側（待たされる側）のＣＰＵには待ちサイクルが挿入されて、優先側のＣＰＵが処理終了後、待機側のＣＰＵの処理が遂行される。ここで言う処理の優先度は、アクセス要求の到着順であることが多い。
【００３１】
ＣＰＵ１（１０１）はローカルバス１１０を介してローカルＲＡＭ１（１１１）、ローカルＲＯＭ１（１１２）と接続されている。同じくＣＰＵ２（１０２）もローカルバス１２０を介してローカルＲＡＭ２（１２１）、ローカルＲＯＭ２（１２２）と接続されている。ローカルバスで接続されてデバイス同士は最も高速でデータの読み書きをすることができる。即ち、｛ＣＰＵ１（１０１）・ローカルＲＡＭ１（１１１）・ローカルＲＯＭ１（１１２）｝と｛ＣＰＵ２（１０２）・ローカルＲＡＭ２（１２１）・ローカルＲＯＭ２（１２２）｝の組では、高速にデータをやり取りできる。
【００３２】
しかしながら、ローカルバスを異にするデバイス間のデータのやり取りは低速になる。例えば、ＣＰＵ１（１０１）がローカルＲＡＭ２（１２１）やローカルＲＯＭ２（１２２）とのデータのやり取りをする場合は、アクセスが低速になる。これはＣＰＵ２（１０２）がローカルＲＡＭ１（１１１）やローカルＲＯＭ１（１１２）とデータのやり取りをする場合も同様である。
【００３３】
一方、共通バス１０３に繋がったデバイス、共有ＲＡＭ１０４、共有ＲＯＭ１０５、Ｉ／Ｏデバイス１０６、割り込みコントローラ１０７にＣＰＵ１（１０１）やＣＰＵ２（１０２）がアクセスする場合は、どちらも中程度の速度で実行可能である。
【００３４】
アクセス可能速度の速さ（アクセス負荷の小ささ、もしくはアクセスコストの低さ）の順で以上の性能を纏めると次のような不等式になる。
【００３５】
ローカルバス同士で繋がったデバイス間のアクセス＞共通バス１０３で繋がったデバイス間のアクセス＞ローカルバスを異にするデバイス間のアクセス  
割込みコントローラ１０７は、ＣＰＵ１（１０１）とＣＰＵ２（１０２）の両ＣＰＵから操作可能であり、互いのＣＰＵに割込みをかける用途に使うことができる。
【００３６】
ＣＰＵ１（１０１）からＣＰＵ２（１０２）に割込みをかける場合は、該コントローラの所定の設定より、割込み信号線１０７ｂを用いる。逆に、ＣＰＵ２（１０２）からＣＰＵ１（１０１）に割込みをかける場合は、割込み信号線１０７ａを用いる。
【００３７】
ここで、複数コア用組込みＯＳの２大類型（ＳＭＰとＦＤＭＰ）について解説を行う。
【００３８】
＜＜対称型マルチプロセッサ（ＳＭＰ：Ｓｙｍｍｅｔｒｉｃ  ＭｕｌｔｉＰｒｏｃｅｓｓｏｒ）ＯＳについて＞＞
ＳＭＰは、アプリケーションプログラムから見ると、どのプロセッサも対等に見える。どのプロセッサも対等なので、各タスクがいずれのプロセッサでも実行できる。そのためＯＳには、各プロセッサに動的に負荷を分散することで高い処理性能を引き出すことが求められる。たとえば、複数のプロセッサを用いて依存性のない複数の処理を並列に実行することでスループットの向上を図る。タスクをどのプロセッサで実行するかは、ＯＳが動的に決定して割り当てる。
【００３９】
＜対称型マルチプロセッサ（ＳＭＰ）ＯＳのメリット（箇条書き）＞
・動的な負荷分散が可能で、システムのスループットを向上させることが可能である。
・ＯＳがタスクをプロセッサに動的に割り付けるため、アプリケーションの作りこみなしで性能を上げられる可能性がある。
【００４０】
＜対称型マルチプロセッサ（ＳＭＰ）ＯＳのデメリット（箇条書き）＞
・すべてのリソースを各プロセッサからアクセス可能とするために、高速で複雑なバスやコヒーレントキャッシュが必要不可欠である。よって、ハードウェアのコストや消費電力は大きくなる傾向にある。
・動的な負荷分散を行うため、各タスクのリアルタイム性の保証が困難になる。
【００４１】
＜＜機能分散マルチプロセッサ（ＦＤＭＰ：Ｆｕｎｃｔｉｏｎ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ）ＯＳについて＞＞
ＦＤＭＰでは、どのタスクをどのプロセッサで実行するかは、システム設計時にアプリケーションエンジニアが決定し割り振る。そのためＯＳは、プロセッサごとに独立にタスクスケジューリングを行えばよいことになる。したがってレディーキューもプロセッサごとに独立して持つことになる。
【００４２】
分割した機能をそれぞれ１つのプロセッサに専用に割り当て、全体としてシステムの機能を実現する方法を取る。この方式では、アプリケーションエンジニアがタスクを静的にプロセッサへ割り付ける必要があり、アプリケーション開発時の手間は増える。
【００４３】
一方、特定のプロセッサのみからアクセスされるハードウェア資源をそのプロセッサにローカルに接続することができるため、プロセッサ間の結合バスにかかる負荷を下げることができハードウェアのコストや消費電力を抑えることができる。
【００４４】
また、スケーラビリティやリアルタイム性の確保もＳＭＰ型に比べると容易である。
【００４５】
＜機能分散マルチプロセッサ（ＦＤＭＰ）ＯＳのメリット（箇条書き）＞
・機能を固定することで，ソフトウェア（ＯＳ）やハードウェア構成を用途に応じて最適化することが可能である。
・プロセッサ間でコードを共有しないため、コヒーレントキャッシュ等の複雑な回路を必要としない。バス構成やメモリ階層を多段（共有とローカルの二段構成、図１を参照）にして性能向上を図ることが可能である。
・個別のプロセッサの性質はシングルプロセッサに近く、ＳＭＰ型と比較してリアルタイム性の保証が容易である。
【００４６】
＜機能分散マルチプロセッサ（ＦＤＭＰ）ＯＳのデメリット（箇条書き）＞
・ＯＳでは動的な負荷分散をサポートしていないため、アプリケーションレベルで実現する必要がある。（裏を返せば、動的な負荷分散を必要としない用途では実質的なデメリットは無い。）
以上、複数コア用組込みＯＳの２大類型の比較を行ったが、本発明の技術は後者の機能分散マルチプロセッサ（ＦＤＭＰ）ＯＳについてのものである。
【００４７】
機能分散マルチプロセッサ（ＦＤＭＰ）ＯＳは、リアルタイム性、特にハードリアルタイム性が保証しやすい利点から、エンジン制御や車体制御など従来からのクリティカルな用途向けの車載制御用マルチコアＯＳとして、マルチコアＣＰＵ世代に多く使われるものと予想される。
【００４８】
ここでハードリアルタイム性とは、制御に課せられたある処理がデッドライン内に終了しなかった時（デッドラインミス）、制御全体にとって致命的なダメージが生じ無価値となる、といった理由から、デッドライン内での終了が保証されなければならない性質のことである。
【００４９】
図２は、本発明の実施例におけるソフトウェア的な機能概念図を示したものである。ＦＭＤＰ型であるのでＣＰＵ１（１０１）に対しては独立したＯＳ１（２１０）が実装され、同じくＣＰＵ２（１０２）に対してはＯＳ２（２２０）が実装される。ＯＳ１（２１０）にはレディーキュー２１１が一セット、同じくＯＳ２（２２０）にはレディーキュー２２１が一セット、各々独立に存在し、通常この二つのレディーキューの間には何の関係もない。（ＯＳの動的データ構造の用語であるレディーキュー等については、後述の図４「ＯＳの状態遷移と関連キューの動作」にて解説する。）
レディーキューはタスクの優先度で分類されて配列化されており、該当優先度のエントリ（登録場所）に実行可能状態になったタスクのタスクコントロールブロック（以下、ＴＣＢと略記）がキューにより待ち行列を形成している。（図２の２１１と２１２、もしくは２２１と２２２の配置関係を参照）
ＯＳは、ＯＳ実行割り込みごとに現在実行状態にあるタスクの優先度と、レディーキューにＴＣＢが繋がれたタスクの最高優先度を比較する（ＯＳはレディーキューをタスク優先度順・実行要求到着順にスキャンする。）
もしレディーキューに繋がれているタスクの最高優先度が実行タスクよりも高いものを発見した場合、現在のタスクの実行を中断し（途中状態を保存して）実行タスクのＴＣＢをレディーキューに差し戻す（これをプリエンプションと言う。）
そしてレディーキューで見つけた優先度のより高いタスクのＴＣＢを、レディーキューから外して、そのタスクを実行状態とする。
【００５０】
タスクの実行が終了すれば、ＴＣＢはタスク休止状態（２１４もしくは２２３）に遷移し、ＴＣＢはどのキューにもリンクされなくなる。
【００５１】
所定のＴＣＢの一つをピックアップして、データ内容の概略を例示したものをＴＣＢ２１３に示す。
【００５２】
通常ＴＣＢには、レディーキューや後述の待ちキューを構成するキューリンク２３１ａとＴＡＳＫ本体２１５を指し示すポインタを含んだ自ＯＳのＴＡＳＫ情報２１３ｂで構成されている。
【００５３】
それに加えて本発明による一実施例では、他ＯＳのレディーキュー２２１や他ＯＳに属するタスクのＴＣＢ２２３を指し示すポインタ等の情報で構成された、他ＯＳのＴＡＳＫ情報２３１ｃも該当ＴＣＢに格納される。
【００５４】
自タスクと連携して起床させる他ＯＳに属するタスクが存在しない場合は、該他ＯＳのＴＡＳＫ情報２３１ｃは空でよいので、本発明を実施しない通常ＯＳのＴＣＢと等しくなる。
【００５５】
一連の機能動作の進行を解説すると、まず、ＯＳ１（２１０）が所定のタスク（ここではＴＣＢ２１３で登録されたタスク）の実行状態履歴からある条件が成立したことを検知したと仮定する。この条件とは、一例としてタスクがＮ回実行され、Ｎ回目の節目として実行状態から休止状態２１４に移行したイベントを想定しても良い。このときＯＳ１はＴＣＢ２１３のタスクと連携してＯＳ２の休止状態２２３にあるタスクをＯＳ２（２２０）の関与無しに直接的に起床させようとする。
【００５６】
このとき、ＯＳ１（２１０）の司令を受けたＣＰＵ１（１０１）は、ＯＳ２（２２０）配下のデータ構造にアクセスするためにＣＰＵ２（１０２）をロックし、データアクセス２１６を行う。即ち、ＯＳ２（２２０）配下で状態的に休止状態２２３であった関連タスクのＴＣＢをＯＳ２のレディーキュー（２２１）に繋ぎ、該タスクを実行可能状態にすることができる。
【００５７】
このアクションの元になる情報が、前述のＴＣＢ２１３に格納された他ＯＳのＴＡＳＫ情報２３１ｃである。
【００５８】
したがって、このようなＦＤＭＰ型マルチプロセッサＯＳで、ＴＣＢの中に他ＯＳのデータ構造を指し示す部分がコードダンプやデバッガにより判明すれば、本発明で開示した目的や手段を流用していることは明らかである。本発明の適用検出方法をここ明示する。
【００５９】
図３は、シングルコアからマルチコアへのタスクの振り分けと流用の手法を示したものであって、これによって前述したマルチコア形態に変更することにより立ち現れる、マルチコア特有の課題も合わせて解説したものである。ここで解説する課題は、本発明を行う動機となったものである。
【００６０】
図３の左図は、シングルコア形態でのタスクの連携を示したものであり、タスクとタスクを繋ぐ矢印はデータフロー（処理データの流れ）を示したものである。
【００６１】
入力タスク２ｍＳ（３００）と入力タスク５ｍＳ（３０１）はセンサ値のＡ／Ｄ変換よる取り込みタスクを想定したもので、その起動周期はデジタルフィルタのサンプリングタイムで決定されており微小時間周期で実行される。
【００６２】
途中のデータ処理タスク１０ｍＳ（３０２）と状態遷移タスク１０ｍＳ（３０３）は図では一応１０ｍＳ周期で起動されるが、その本質はイベント的であり、入力タスクに新たな入力データが準備されれば起動するか、もしく状態遷移トリガとして入力値に有意な変化があれば起動されるイベント的な処理タスクである。
【００６３】
最後のデータフローが行き着くタスクである出力タスク５０ｍＳ（３０４）と出力タスク１００ｍＳ（３０５）はこれも所定時間ごとに周期的に実行されており、その実行周期は出力アクチュエータの時間分解能で決定される。
【００６４】
以上により時間周期タスクは３００、３０１、３０４、３０５、イベント駆動的なタスクは３０２、３０３と分類される。
【００６５】
これらのシングルコア・アプリケーションをマルチコアに振り分けたのが図３右図であり、一例として主に時間周期タスクをタスクセット３１０としてＣＰＵ１（１０１）に割り当て、イベント駆動的なタスクをタスクセット３２０としてＣＰＵ２（１０２）に割り当てることにする。
【００６６】
前述のＦＤＭＰ型マルチプロセッサＯＳを採用しているので、ＯＳ１（２１０）に対しては独立した一本のレディーキュー２１１、ＯＳ２（２２０）に対しては同じく一本のレディーキュー２２１が設定され、これらレディーキューは基本的には相互に独立かつ無干渉であるので、このままでは時間的タスクセット３１０とイベント的タスクセット３２０のスケジュール連携を取る手段が無いことになる。
【００６７】
ここでこれを解決するために考案されたのが本発明であって、例えばタスクセット３１０に属する入力タスク２ｍＳ（３００）が５回実行されるごとに、もしくは入力タスク５ｍＳ（３０１）が２回実行されるごとにタスクセット３２０に属するデータ処理タスク１０ｍＳ（３０２）もしくは状態遷移タスク１０ｍＳ（３０３）を起床させたいと言う用途に用いることができる。
【００６８】
ちなみにタスクセット３１０に属する出力タスク５０ｍＳ（３０４）および出力タスク１００ｍＳ（３０５）の時間制約は上記の入力タスク（３００、３０１）と処理タスク（３０２、３０３）の連携ほどシビアではなくて、定期的に起床する出力タスク（３０４、３０５）の各々についてその時点でのタスクセット３２０の最新の処理結果を使えれば良いものとする。
【００６９】
以上、異なるＣＰＵ及び異なるＯＳ間のタスク起床スケジュールの連携について見てきたが、異なるＣＰＵ及び異なるＯＳ間のデータフローについてもマルチコア特有の問題が発生する。それは、共有メモリ１０４を通じたタスクセット３１０と３２０間のデータのやり取りに現れる。
【００７０】
このやり取りをシーケンス図に表記したのが図３右図・下半分のシーケンスチャートである。
【００７１】
一例としてタスクセット３１０に属する書き込みタスク３１１が一連のデータの組をタスクセット３２０に属する読み出しタスク３２１に送ることを考える。
【００７２】
二つのＯＳに別々に属し、まったく無関係なタイミングで活動する書き込みタスク３１１と読み出しタスク３２１の間で健全なデータの組をやり取りするには、共有資源の排他制御機構であるロック３３０を活用する。
【００７３】
ここでの共有資源は、データの受け渡しに用いる共有メモリ１０４であり、如何にロック３３０を用いてデータのやり取りを行うかを、シーケンス図の時間軸ｔの経過に従って解説する。
【００７４】
書き込みタスク３１１では時点ｔ１で割り込み禁止とし、同一ＣＰＵ内排他制御に移行する。その上で、時点ｔ３でロック３３０の取得を試み複数ＣＰＵ間での排他制御を試みる。
【００７５】
時点ｔ１で割り込み禁止とする理由は、ロック取得中に割り込み処理が入ると複数ＣＰＵ間での競合時間（ロックの取得から解放までの必要時間）の最悪値を保証できなくなり、リルタイム性が保証できなくなるためである。
【００７６】
書き込みタスク３１１は時点ｔ４でロック３３０の取得に成功するので、共有メモリ１０４に対するアクセス権を得、時点ｔ８で最新データの書き込みを行う。
【００７７】
一方、読み出しタスク３２１は時点ｔ２で割り込み禁止にし、読み出しのために時点ｔ５でロック３３０を取得しようとする。しかしながら、時点ｔ６でこれが失敗するので（書き込みタスクの方が先にロックを取得しているので）、時点ｔ７で割り込み禁止を解除し、読み出しを次の機会に先送りする。
【００７８】
次に時点ｔ８で書き込みを完了した書き込みタスク３１１は、時点ｔ９でロック３３０を解放し、時点ｔ１１で割り込み禁止を解除して一連のデータ送信処理を終了する。
【００７９】
一方読み出しタスク３２１は、時点ｔ１０で再度共有メモリ１０４に対するアクセスを試みる。時点ｔ１０で割り込み禁止とし、時点ｔ１２でロック３３０を取得しようとする。今回は、事前にｔ９で書き込みタスク３１１がロック３３０を解放しているので、時点ｔ１３でロックの取得に成功し、結果として時点ｔ１４でデータの読み出しを行う。引き続き時点ｔ１５でロック３３０の解放を行い、時点ｔ１６で割り込み禁止を解除して一連のデータ受信処理を終了する。
【００８０】
以上、述べたようにマルチコアシステムに移行することにより、シングルコアでは問題ならなかったＯＳを跨いだスケジュール連携の問題と、ロック機構を用い共有メモリを介したデータ授受の問題が、新たに立ち現れることが理解できると思う。
【００８１】
以上の議論では、マルチコアとして２つのＣＰＵを内蔵した２コアについて述べてきたが、これは２コア以上のＮコアに対しても同様であって、今まで述べたような同様の議論が通用し、本発明における同様の手法が適用可能なことは言うまでもない。
【００８２】
図４に、複数コア各々で実行されているＯＳの状態遷移と関連キューの動作を示す。
【００８３】
また、図５に各コアのＯＳのタスクコントロールブロック（ＴＣＢ：Ｔａｓｋ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）の詳細を例示する。図４と図５に基づき各ＯＳで実施されているタスクの状態遷移を以下に解説する。
【００８４】
先ず、タスクコントロールブロックの内容の解説を図５に従い行う。タスクコントロールブロック５００はタスクのそれぞれについて一対一で対応するように作られるデータの構造体であり、レディーキュー（待ちキュー）リンク５００、自ＯＳのタスク用データエントリ５１０、本発明の核心的部分である他ＯＳのタスク用データエントリ５２０で構成される。
【００８５】
レディーキュー（待ちキュー）リンク５００はレディーキューおよび待ちキューを構成するときに用いられるポインタを格納する。
【００８６】
自ＯＳのタスク用データエントリ５１０は、タスクの実行状態５１１、タスクの実行優先度５１２、タスク本体の開始アドレス５１３、コンテキスト待避用のスタックアドレス５１４、中断時のコンテキスト保管状況５１５（実行中断時のスタック消費量、メモリイメージで待避できないフラグの状態、待ち状態で中断している場合どの種類の待ちを行っているか等の情報、を保管している）などの内容のデータで構成されている。
【００８７】
以上は、通常の組込みＯＳのタスクコントロールブロック内容にほぼ準拠している。
【００８８】
しかしながら、次の他ＯＳのタスク用データエントリ５２０の追加拡張が本発明の核心的部分である。これは、通常のタスクコントロールブロックの内容に加えて、「本タスクに関連付けられた他ＯＳタスクの起床条件５２１」、「他ＯＳのレディーキューへのポインタ５２２」、「他ＯＳタスクのタスクコントロールブロックへのポインタ５２３」の情報を新たにデータ構造に付け加えるものである。
【００８９】
タスクの状態遷移を図４に従って見ていくと、ＤＯＲＭＡＮＴ休止状態４００、ＲＥＡＤＹ実行可能状態４０１、ＲＵＮ実行状態４０２、ＷＡＩＴ待ち状態４０３の各々の状態は、タスクコントロールブロック５００の中のタスクの実行状態５１１エントリで保管・管理される。
【００９０】
先ず、ＤＯＲＭＡＮＴ休止状態４００であったタスクは、起床条件が来た場合ＲＥＡＤＹ実行可能状態４０１へと状態遷移を行う。これは、休止状態のタスクコントロールブロック４１０が、レディーキュー４１１の待ち行列に挿入されることを意味する。レディーキュー４１１は、タスク優先度順に分類されたタスクコントロールブロックの待ち行列で構成されており、同一優先度ではタスクは到着順で待ち行列に入る。
【００９１】
ＯＳは次のディスパッチタイミング（ＯＳチックタイムというシステムで設定された微小時間で定期的に目覚める場合と、アプリケーションその他がタスク起床用ＡＰＩをコールしてその事象で目覚める場合とがある。本発明では後述するが後者の類似の仕組みを使って他ＯＳのタスク起床を行う。）でＲＵＮ実行状態４０２にあるタスクの優先度とレディーキュー４１１中の最高優先度タスクとの優先度比較を行う。
【００９２】
もし、ＲＵＮ実行状態４０２のタスクが無いか、レディーキュー４１１中の最高優先度タスクの方が高ければ、レディーキュー４１１より該当タスクコントロールブロックを外して実行状態４１２とする。すでに実行状態４１２であって、新たに優先度の高いタスクに実行を譲って中断したタスクは、その時のコンテキストを保存してレディーキュー４１１に繋ぎ戻される。（これもプリエンプトと称する。）
ＲＵＮ実行状態４０２にあるタスクが他タスクと排他的資源を取り合って「待ち」に入る場合、もしくは通信や他の何らかのイベントを待って「待ち」に入る場合は、図５のＷＡＩＴ待ち状態４０３に遷移する。タスクコントロールブロックは、「待ち」の要因に相当する排他的資源の種類別の待ちキュー４１３や、「待ち」の要因に相当するイベントの種類別の待ちキュー４１４に繋がれる。
【００９３】
上記の待ち条件が解消されると、該当タスクコントロールブロックは、待ちキュー４１３・４１４より外され、レディーキュー４１１に繋ぎ戻されて、ＲＥＡＤＹ実行可能状態４０１へと遷移する。
【００９４】
ＲＵＮ実行状態４０２にあるタスクが処理を無事に終了すると、タスクコントロールブロック４１２がＤＯＲＭＡＮＴ休止状態４００へと遷移し、休止状態のタスクコントロールブロック４１０となる。
【００９５】
このときに、図５のタスクコントロールブロック５００の「本タスクに関連付けられた他ＯＳタスクの起床条件５２１」がＯＳによりチェックされる。
【００９６】
例えば、その条件が「該当タスクがＮ回走行した場合他ＯＳの特定タスクを起床させること」であって、その条件が成立した場合は、ＯＳは次の「他ＯＳのレディーキューへのポインタ５２２」、「他ＯＳタスクのタスクコントロールブロックへのポインタ５２３」の情報を元に、他ＯＳのデータ構造に介入して該当タスクを起床させようとする。
【００９７】
その方法の概要と手続きを以下の図６、図７を参照して解説する。
【００９８】
図６は、自ＯＳから他ＯＳに所属するタスクを直接起床する（直接操作法による）手続きを示す概念図である。以下手順を箇条書きより列記し、処理の詳細を例示する。
【００９９】
＜直接操作法による処理の流れ＞
ｏｐ６１:ＯＳ１（２１０）によりタスクがレディーキュー２１１より取り出され、実行終了し休止状態２１４に戻される前に、他ＯＳの関連タスクを起床する条件（図５の５２１として前述）が成立しているかどうかが調べられる。該条件が成立すれば以下の手続きを実行する。
ｏｐ６２：ＣＰＵ１（１０１）から直接ＣＰＵ２（１０２）のローカルメモリ６０１にあるタスクコントロールブロックを操作する。具体的にはＣＰＵ１と２間のインターコネクション６０２を通じて、休止状態２２３にあるタスクコントロールブロックをＯＳ２（２２０）のレディーキュー２２１に繋げる。（該当レディーキュー２２１の場所と該当休止タスクのタスクコントロールブロックの場所は、図５の５２２および５２３として前述している。）（各々のＯＳのデータ構造６００と６０１は、図１のローカルメモリＲＡＭ１（１１１）とＲＡＭ２（１２１）に搭載されていることを想定しているが、共有ＲＡＭ１０４に搭載されていても良い。その際にはアクセスが異なるＣＰＵのローカルバス上の操作から、共通バス上の操作に変更されるので、上記繋ぎ替え処理は高速化されるであろう。）
ｏｐ６３：ＣＰＵ２（１０２）は、ｏｐ６２の結果ディスパッチが必要になったことを知らないので、ＣＰＵ１（１０１）からＣＰＵ間割込みで通知する。これは具体的には図１の割込みコントローラ１０７の割込み信号線１０７ｂによって実施する。
ｏｐ６４：ＣＰＵ２（１０２）でディスパッチが発生し、該当関連タスクが実行状態となる。
【０１００】
以上の動作を行う手続きの詳細をフローチャートに纏めて図７に例示する。
【０１０１】
図７は、自タスクが図４でＲＵＮ実行状態４０２からＤＯＲＭＡＮＴ休止状態４００に移行するときにＯＳが行う動作をフローチャートに示したものである。ステップＳ７０１では自タスクの処理が終了したかどうかがチェックされ、終了していなければステップＳ７０１の前でループしてタスクが終了するまで待つ。
【０１０２】
終了すれば、次のステップＳ７０２で図５の「本タスクに関連付けられた他ＯＳタスクの起床条件５２１」がＴＣＢ５００より参照されチェック（ステップＳ７０３）が行われる。その結果、他ＯＳの関連タスクの起床条件が成立しなければ、ステップＳ７１７に飛んで通常の自タスク終了処理を行い、全体のフローを終了する。
【０１０３】
他ＯＳの関連タスクの起床条件が成立していれば、次の処理ブロックＢ７０１に進行する。
【０１０４】
処理ブロックＢ７０１は、図３で示したようにロック変数を用いて他のＣＰＵとの間で排他制御を行う区間である。いわゆるスピンロックと称される複数プロセッサ間排他制御区間である。（厳密にはスピンロックという用語は、後述のアトミック命令の結果を用いてロックが取得できるまで、ロックの取得を試みる方法であり、Ｓ７０５からＳ７０７の一連の処理、およびＳ７０６→Ｓ７０８→Ｓ７０５のループ処理が相当する。）
ステップＳ７０４で割込み禁止を行いＣＰＵ内排他処理に切り替える。これは割込みを許すとロックを取得したＣＰＵのロック保持時間が割込みにより不確定となり、同じロックを待つ他のＣＰＵの最悪ロック待ち時間もこれに引きずられて不確定となって、リアルタイム制御に支障が出るからである。
【０１０５】
ステップＳ７０５でロック変数の読み込みを行い、続くＳ７０６でロック変数が解放されているかをチェックし、続くＳ７０７でロック変数に使用中のマークを書いて自ＣＰＵの変数として取得する。Ｓ７０６とＳ７０７はアトミック（不可分）な命令Ｂ７０２として実装されている。
【０１０６】
ロックは一般にハードウェアによるサポートを必要とする。通常、1つ以上のアトミック命令を使用して実装される。（「テスト・アンド・セット」、「ロードリンクト ストアコンディショナル」、「フェッチ・アンド・アッド」、「コンペア・アンド・スワップ」など。）
これらのアトミック命令は，ロックが獲得されていないことをチェックするとともに、不可分な処理としてロックを獲得することができる。現在のマルチプロセッサのほとんどがハードウェア的な排他制御機構を持ち、そのためのアセンブリ命令を備えている。アトミック命令とは、Ｂ７０２のように実際にはいくつかの操作を組み合わせた命令だが、他のプロセッサから見てそれらがひとつの処理に見えるものをいう。
【０１０７】
アトミック命令の中の一部の操作が失敗した場合は、アトミック命令全体が失敗したことになり、システムの状態はアトミック命令を発行する前の状態に戻る。
【０１０８】
ロック変数の取得に成功すると、ステップＳ７１２に進み、失敗するとステップＳ７０８に進む。
【０１０９】
ステップ７０８ではスピンロック中に割込みがかかっていたかをチェックし、かかっていなければステップＳ７０５に戻って再度スピンロックを試みる。かかっていれば、ステップＳ７０９でいったん割込み禁止を解除し、ステップＳ７１０で割り込み処理を行い、ステップ７１１で再度割込み禁止にしてステップＳ７０５に戻りスピンロックを再試行する。
【０１１０】
この一連の動作の意味は、ロックの取得は、割込み禁止にしてプロセッサ内排他制御を行ってから行う。しかし、そのままではロックの取得がすぐに行われない場合は、割込み遅延時間がどんどん長くなってしまう。そこで、スピンロックによりロックの取得を試みている間は、試行毎に割込みをチェックし、割込み要求がある場合は、いったん割込みを許可するという方法をとっている。これによりロック取得を原因とする割込み遅延時間の上限を確定することができ、リアルタイム制御を保証することができる。
【０１１１】
ロックが取得出来れば、複数プロセッサ間の排他制御が保証されることになる。
【０１１２】
ステップＳ７１２で自タスクのタスクコントロールブロックより他ＯＳのタスクのタスクコントロールブロック位置とレディーキュー位置を示すポインタを取得する。これは図５で、「他ＯＳのレディーキューへのポインタ５２２」、「他ＯＳタスクのタスクコントロールブロックへのポインタ５２３」として示しているものである。
【０１１３】
これらの情報を元に、ステップＳ７１３では他ＯＳのレディーキューへ関連タスクのタスクコントロールブロックを挿入し、関連タスクを実行待ち状態に遷移させる。この操作は、図６のｏｐ６２で解説した操作と同一である。
【０１１４】
続くステップＳ７１４では、他ＯＳへ割込み信号を出力しディスパッチ要求があることを通知する。この操作は、図６のｏｐ６３で解説した操作と同一である。
【０１１５】
一連の他ＯＳのタスク起床操作が終了するとステップＳ７１５でロック変数を解放し、複数プロセッサ間排他制御から抜ける。つづく、ステップＳ７１６で割込み禁止を解除しプロセッサ内排他制御を抜ける。
【０１１６】
以上によりスピンロック区間（複数プロセッサ間排他制御区間）Ｂ７０１から脱出したことになる。
【０１１７】
続くステップＳ７１７では通常の自タスク終了処理を行い一連のフローを終了する。
【０１１８】
上記の実施例で明らかになった本発明の要点と効果を以下に纏める。
【０１１９】
機能分散マルチプロセッサ（ＦＤＭＰ型）について、原理的には非同期・無関係である複数プロセッサに跨がったタスクを、連携して起動することを可能とする効果がある。
【０１２０】
連携して他ＯＳのタスクを起床させるために、他ＯＳのレディーキューやタスクコントロールブロックのリンクを直接操作法で操作する。
【０１２１】
操作のための基本情報と操作を行うべき条件は自タスクのタスクコントロールブロックに格納される。これらの情報は、ＯＳ構成時にあらかじめ静的に翻訳・格納されるので、本発明に基づく制御で高速に参照することが可能である。
【０１２２】
また、これらの情報は、アプリケーションプログラマが直接実装しないので、アプリケーションコードにＡＰＩの形で混ざり、アプリケーション部品化の障害となることが無い。
【０１２３】
操作には、複数プロセッサ間の排他制御のためにスピンロック機構を利用し、他ＣＰＵのローカルメモリ上のデータ構造に直接アクセスする。
【０１２４】
他ＣＰＵのローカルメモリ上のデータ構造にアクセスするにはアクセスコストがかかるので、これらのデータ構造を共有メモリ上に配置すると高速にアクセス可能でありＯＳのスループットが向上する。
【０１２５】
以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【０１２６】
特に、ＣＰＵコアは実施例で述べたように２個に限定するものではなく、Ｎ個のメニープロセッサに拡張可能である。
【０１２７】
また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできるし、集積回路と密接に関連したデバイス制御言語もしくはファームウェアとして実現することもできる。
【符号の説明】
【０１２８】
１００：ＭＰＵ、１０１：ＣＰＵ１、１０２：ＣＰＵ２、１０３:共通バス、１０４：共有ＲＡＭ、１０５：共有ＲＯＭ、１０６：Ｉ／Ｏ、１０７：割込みコントローラ、
１１０：ＣＰＵ１側ローカルバス、１１１：ローカルＲＡＭ１、１１２：ローカルＲＯＭ１、
１２０：ＣＰＵ２側ローカルバス、１２１：ローカルＲＡＭ２、１２２：ローカルＲＯＭ２
２１０：ＯＳ１、２１１：ＯＳ１のレディーキュー、２１２：ＯＳ１のレディーキューに繋がったＴＣＢ、２１３：ＴＣＢ詳細、２１４：休止状態ＴＣＢ、２１５：タスクの実行コード本体、２１６：ＣＰＵ１によるＯＳ２データ構造の直接操作、
２２０：ＯＳ２、２２１：ＯＳ２のレディーキュー、２２２：ＯＳ２のレディーキューに繋がったＴＣＢ、２２３：休止状態ＴＣＢ。
【図１】
2018049406.tif 000003
【図２】
2018049406.tif 000004
【図３】
2018049406.tif 000005
【図４】
2018049406.tif 000006
【図５】
2018049406.tif 000007
【図６】
2018049406.tif 000008
【図７】
2018049406.tif 000009