JP5299681B2 - プログラム検査方法 - Google Patents

プログラム検査方法 Download PDF

Info

Publication number
JP5299681B2
JP5299681B2 JP2009032691A JP2009032691A JP5299681B2 JP 5299681 B2 JP5299681 B2 JP 5299681B2 JP 2009032691 A JP2009032691 A JP 2009032691A JP 2009032691 A JP2009032691 A JP 2009032691A JP 5299681 B2 JP5299681 B2 JP 5299681B2
Authority
JP
Japan
Prior art keywords
program
executed
operation test
node
test
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
Application number
JP2009032691A
Other languages
English (en)
Other versions
JP2010191522A (ja
Inventor
寿 小熊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toyota Motor Corp
Original Assignee
Toyota Motor Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toyota Motor Corp filed Critical Toyota Motor Corp
Priority to JP2009032691A priority Critical patent/JP5299681B2/ja
Publication of JP2010191522A publication Critical patent/JP2010191522A/ja
Application granted granted Critical
Publication of JP5299681B2 publication Critical patent/JP5299681B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Description

本発明は、プログラム検査方法に関し、特に、マルチコアシステムにおいて短時間かつ正確に動作試験を実行可能なプログラム検査方法に関する。
近年の組み込み機器分野では、低電力化や部品点数の削減による低コスト化への要求に対する対応として、1チップに複数のCPUコアを搭載するマルチコアプロセッサの利用が進められている。マルチコアプロセッサでは、各コアで処理を並列に実行することで高性能化しつつ低電力化を図ることができる。
たとえば車載システムにおいては、車両のエレクトロニクス化に伴う電子制御ユニット(ECU)数の増加が問題となっている。そこで、マルチコアプロセッサを利用して、従来いくつかのECUとして構成されていたものを1つに統合してECU数を抑制することが行われている。このような車載システムはマルチコアプロセッサを有する複数のノードから構成されるマルチコア分散処理システムの一例である。
ネットワーク接続された複数のノードから構成されるシステムにおいて、あるノードでソフトウェアの更新・変更をした場合、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定される処理が正常に動作することを確認するための動作試験を行うべきである。マルチコアシステムにおいては、複数の処理を並列に実行できるため、複数の動作試験プログラムを並列して実行することで試験時間を短縮可能である(特許文献1)。
特開2000−236388号公報
しかしながら、特許文献1に記載の技術では、プロセッサ間で共有するデバイスについての考慮がなされていない。動作試験の実行を短時間で行うため複数の試験プログラムを並列に実行する場合は、実際の動作環境では生じないようなデバイス競合が発生する可能性が高まる。デバイス競合が発生してしまうと、試験と実際の動作で環境が異なってしまい正しい試験が行えない。また、デバイスが利用可能となるまで処理が待ち状態となるため、演算資源を有効に利用できず試験時間も長引いてしまう。
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、マルチコアプロセッサをノードに採用したマルチコアシステムにおいて、デバイス競合による悪影響を回避して動作試験を短時間かつ正確に実行可能な技術を提供することにある。
上記目的を達成するために本発明では、以下の手段または処理によってマルチコアシステムにおいてプログラム検査を行う。
すなわち、本発明は、マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、シス
テム内で複数並列に実行し、
あるノードで実行中のプログラムにデバイス競合が発生した場合に、このプログラムの実行を中断するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する、ことを特徴とする。
このようにデバイス競合時に連携するプログラム全体の動作を中断することで、単独で動作試験を行うのと同様の環境で動作試験を並列実行可能であり、より正確な試験が実現できる。
また、本発明において、ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、その実行可能な動作試験をシステム内で実行することが好ましい。
このように、デバイス競合に伴う動作試験の実行中断により生じた演算資源の空きを利用して別の動作試験を実行することで、演算資源を有効に利用した試験が可能となり、試験の実行時間を短縮することができる。
また、本発明において、実行中のプログラムが正常に動作しているかを監視し、あるノードで実行中のプログラムが正常に動作していない場合に、このプログラムを停止するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する、ことが好ましい。
なお、正常動作とはプログラムが意図された動作を行うことであり、期待する結果と異なる結果が得られた場合にエラーコードを返して終了することなどは正常動作に含まれる。したがって、正常に動作していないとは、プログラムが意図と反して実行を停止してしまう、あるいは実行が停止しているように見える現象を指す。
このように、プログラムが正常に動作していない場合に、連携するプログラム全体の動作を停止することで、演算資源に空きを作ることができる。この演算資源の空きを利用して別の動作試験を実行可能となり、試験の実行時間を短縮することができる。
なお、本発明は、上記処理の少なくとも一部を含むプログラム検査方法として捉えることができる。また、本発明は、このような方法を実現するためのプログラムとして捉えることもできる。また、本発明は、このようなプログラム検査方法を実行するマルチプロセッサシステムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
本発明によれば、マルチコアプロセッサをノードに採用したマルチプロセッサシステムにおいて、動作試験を短時間かつ正確に行うことが可能となる。
図1は本実施形態に係るマルチコアプロセッサシステムの構成を示す図である。 図2はテストの基本的な流れを示すフローチャートである。 図3は各テストケースを構成するプログラムを記憶したテーブルの例を示す図である。 図4は動作試験プログラムのいずれかがデバイスへのアクセスを要求した場合の処理の流れを示すフローチャートである。 図5は競合していたデバイスが解放され利用可能となった場合の処理の流れを示すフローチャートである。 図6Aは複数の動作試験プログラムが並列して実行されることを説明する図である。 図6Bはデバイスへのアクセス競合が発生したときに連携する全てのプログラムの実行が中断されることを説明する図である。 図6Cはある動作試験プログラムの実行中断に伴い別の動作試験プログラムが実行されることを説明する図である。 図7はプログラムのフリーズを監視しフリーズしたプログラムおよび連携するプログラムの実行を停止する処理の流れを示すフローチャートである。
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
<システムの構成>
本実施形態に係るマルチコアシステムは、それぞれがマルチコアプロセッサを有する複数のノードから構成される。各ノードでは複数のプログラムが動作可能であり、ノード内またはノード間のプログラムが連携して1つの処理を実行する機能分散型のシステムを構成する。
本実施形態に係るマルチコアシステムは、たとえば、車載システムに適用することができる。安全運転支援を行う車載システムでは、たとえば、センサを用いて前方の障害物を認識し、一定の距離以下になると運転者への警告や減速制御などを行ったり、シートベルトの巻き取りを行ったりする。また、車外カメラから画像を取得し画像認識により人物や障害物を検知し、運転者に注意を促したりする。このように、安全運転支援を行う車載システムでは、多数のカメラやセンサから種々のデータを取得し、これらのデータをリアルタイムで処理することが求められる。そこで、マルチコアシステムを利用することで、各処理を並列に実行することでリアルタイム処理を実現する。
図1は、本実施形態に係るマルチコアシステムの構成を示す図である。図1に示すように、本システムはそれぞれが複数のプロセッサコアを有する複数のノードから構成される。図1では5つのノードN1〜N5が示されているが、ノード数はいくつであっても構わない。これらのノードはネットワーク40を介して接続されている。
各ノードの構成について説明する。各ノードはハードウェア10として複数のプロセッサコア(ここでは4つのプロセッサコア11〜14)を有する。このようなハードウェア上にスーパーバイザ20を導入し、その上で複数のオペレーティングシステムを動作させる。スーパーバイザ導入によるアクセスオーバヘッドを小さくし、かつ既存機能への変更をできるだけ小さくするために、インテル社のVT−xやAMD社のAMD−Vなどの仮想化技術を採用してプロセッサレベルで仮想化に対応することが好ましい。
スーパーバイザ20は、その機能として連携部21、システム状態監視部22、デバイス状態管理部23を有する。連携部21は、1つのオペレーティングシステムが同一ノードまたは他ノード内の他のオペレーティングシステムとの間で連携を取るための通信を行う。システム状態監視部22は、ノード内で実行中の動作試験プログラムがフリーズしているかを監視し、必要に応じてプログラムの停止や停止理由の記録などを行う。デバイス状態管理部23は、各オペレーティングシステムによるデバイスアクセスを管理し、排他的なデバイス利用を実現する。
各オペレーティングシステムは、上記のようなハードウェアが仮想化されたマルチコアプラットフォーム上で並列に動作する。したがって、各オペレーティングシステムが物理デバイスにアクセスする場合には、システム制御部(31〜33)を介してスーパーバイ
ザ20に要求する。
<プログラムテスト>
このようなマルチコアシステムにおいては、一部のソフトウェアのみを更新した場合であっても、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定されるあらゆる動作について試験を行うべきである。想定されるテストケースの数が多いので、複数のテストケースを並列に実行することでテスト処理を高速に行う。
図2にテストの基本的な流れを示す。まず、マルチコアシステム内での各ノードの演算資源(プロセッサコア)の使用状況を把握する(S101)。次に、実行可能な動作試験プログラム(テストケース)が存在するか判断する(S102)。なお、各テストケースにおいて連係動作するプログラムの関係は、図3に示すような形式でメモリ上に格納されている。図3においては連携するプログラムがX−Y−Zの形式で記載されているが、これはノードX上のオペレーティングシステムY内のプログラムZを表す。このようにテストケースごとに連携するプログラムが記憶されているので、各テストケースを実行するために必要な演算資源を把握できる。したがって、各ノードでの演算資源の使用状況と比較することで、実行可能なテストケースが存在するか否かを判断できる。
実行可能なテストケースが存在しない場合(S102−NO)は、ステップS101へ戻って演算資源の空きができるまで待つ。実行可能なテストケースが存在する場合(S102−YES)には、そのテストケースを実行する(S103)。
次に、全ての動作試験プログラムを実行済みか判断し(S104)、まだ実行すべき動作試験プログラムがある場合(S104−NO)にはステップS101へ戻る。このようにすることで、複数の動作試験プログラムを並列に実行可能である。
なお、上記で説明した図2の処理は、本マルチコアシステム内のいずれかのオペレーティングシステム内のプログラムが実行しても良いし、本マルチコアシステムにテスト用のコンピュータを接続して、このコンピュータで実行をしても良い。また、システム内の複数のプロセッサが連携してこの処理を実行しても良い。
<テストの並列動作における問題>
このように動作試験プログラムを複数並列して実行する場合、複数のプログラムから同一のデバイスに対するアクセスが発生する可能性が高まる。その場合、アクセス競合が発生したプログラムはデバイスが利用可能になるまで処理を行うことができない。
デバイスへのアクセス競合が発生することで、動作試験プログラムの並列実行が阻害され、テストの効率的な実行が妨げられる。演算資源の乏しいシステムやアクセス競合の発生が少ないシステムでは、デバイスが解放されるまでの待機処理をビジーウェイトによって実現することが多い。したがって、演算資源が有効に利用できず、テストの完了に時間がかかってしまう。
また、1つのテストケースは複数のノードで並列実行される複数のプログラムから構成されるため、あるノードでの処理が中断されることでプログラム間の連携のタイミングが狂ってしまう。この場合、正しい処理結果が得られなかったり、エラーが発生したりしてしまう。
これらの問題は、実際のシステム運用時にはコア間でデバイス競合が発生しないようなシステムで顕著なものとなる。そこで、本発明ではデバイス競合時に、連携する全てプロ
グラムの実行を中断することで、動作試験プログラムが単独動作した場合と同じ環境でのテストを実現する。
<デバイス競合時の動作>
まず、図4を参照して動作試験プログラムのいずれかがデバイスへのアクセスを必要とする場合の処理の流れを説明する。
あるプログラムがデバイスへのアクセスを要求する場合、スーパーバイザ20へデバイス利用のための割り込みを発生させる(S201)。この割り込みにより、デバイス状態管理部23が割り込みハンドラとして起動する(S202)。デバイス状態管理部23は、指定されたデバイスが利用中であるか調べる(S203)。デバイスが利用中でなければ(S204−NO)、割り込み発生元のプログラムがそのデバイスを占有利用する(S205)。この場合は、動作試験プログラムが単独で動作している場合と同様であるので、その他の処理は行わない。
一方、指定されたデバイスが利用中である場合(S204−YES)は、デバイスアクセスを要求したプログラムと連携しているプログラムの実行を中断させるために、連携部21を介して他ノードの連携部へ中断を要求する(S206)。なお、中断要求を受信したノードでの処理(S209以降)については、後で説明する。
デバイスアクセスを要求した対象プログラムを実行しているノードは、デバイスが利用可能となるまで、そのプログラムの実行を中断させる(S207)。また、同一ノード内の別のオペレーティングシステムで連携して動作しているプログラムが存在する場合には、連携部21を介して、そのプログラムの実行も中断させる。このように、プログラムの実行を中断させることでコアがアイドルになるので、他に実行すべき動作試験プログラムがあれば実行する(S208)。
次に、ノード間通信を介して他ノードからの中断要求を受信したノードでの処理について説明する。デバイス競合が発生したノードからの中断要求を受信すると(S209)、中断要求を受信したノードで連携部21が動作する(S210)。連携部21は、中断要請元のプログラムと連携するプログラムを中断させるために、対象のシステム制御部に対して連携プログラムの中断を通知する(S211)。この通知を受け取ったシステム制御部は、対象のプログラムの実行を中断する(S212)。
このような処理により、動作試験プログラムを構成するいずれかのプログラムでデバイス競合が発生し処理の継続ができなくなった場合に、動作試験プログラムを構成する全ての連携プログラムを、システム内で同時に中断させることができる。また、それによりリソースに空きができた場合に、他の動作試験プログラムを実行できる。
<デバイス解放時の動作>
次に、図5を参照して、競合していたデバイスが利用可能となった場合の処理について説明する。デバイスが解放されて利用可能になると(S301)、デバイス状態管理部23が起動する(S302)。そしてデバイス状態管理部23が、中断していたプログラムに対応するシステム制御部を動作させる(S303)とともに、他ノードの連携部に中断していたプログラムの実行再開を要求する(S304)。システム制御部は、対象プログラムの実行を再開させる(S305)。
ノード間通信を介して他ノードからの再開要求を受信(S306)したノードでは、この指示を受けてノード内の連携部を動作させる(S307)。連携部は、対象のシステム制御部に対して連携プログラムの実行再開を通知する(S308)。この通知を受けて、
システム制御部は対象プログラムの実行を再開する。
このような処理により、デバイス競合によって実行が中断されていた動作試験プログラムを再開させることができる。なお、デバイスが解放された場合であっても、プロセッサコアに空きがない場合はこの動作試験プログラムを実行できないので、その場合はデバイスとともにプロセッサコアが利用可能となるまで、実行再開を待つ必要がある。
<動作例>
上記の処理による、具体的な動作試験プログラムの実行例を、図6A〜6Cを参照して説明する。ここでは、各動作試験プログラム(テストケース)が、図3に示すような連携プログラムによって構成されているものとして説明する。
まず、デバイス競合が発生していない状況では、図6Aに示すようにテストケース1〜3が実行される。たとえば、ノードN1では、テストケース1用のプログラム1−1−1,1−3−2、およびテストケース2用のプログラム1−1−2,1−2−1が、並列して実行される。他のノードでも同様に複数のプログラムが並列して実行される。
このように、実際の運用時には1つのケースしか実行されないようなシステムであってもプログラムテスト時には複数のテストケースを並列に実行することで、効率的にテストを実行することができる。
ここで、ノードN1でデバイスへのアクセス競合が発生したとする。たとえば図6Bに示すように、テストケース1におけるプログラム1−1−1がデバイスを利用中に、テストケース2におけるプログラム1−2−1が同時にそのデバイスにアクセスしようとした場合を考える。この場合、プログラム1−2−1の実行を中断するだけでなく、テストケース2を構成する全てのプログラムの実行を中断する。ノードN1内では、ノード内での通信により他のオペレーティングシステム内で実行しているプログラムを中断させる。ノードN3など、デバイス競合が発生したノードN1以外のノードには、ノード間通信によって連携プログラムの中断を指示する。
このようにテストケース2を構成するプログラムのうちの1つがデバイス競合によって実行できなくなった場合は、テストケース2を構成する全てのプログラムの実行が中断される。
テストケース2を構成する全てのプログラムの実行が中断された場合、プロセッサコアに空きができるため、図6Cに示すように実行可能な他のテストケース(ここではケース4)が実行される。
<プログラム異常時の処理>
テスト中にはプログラムが予期しない動作を行い処理が停止してしまうことがある。ここでいう処理の停止とはいわゆるフリーズ(ハングアップともいう)のことを指し、期待する結果と違う結果が得られたり、エラーコードを出力して終了する場合などは含まれない。プログラムがフリーズした場合はプロセッサ資源がこのプログラムに割り当てられたままとなり、他のプログラムに割り当てることができなくなってしまう。そのため、フリーズが発生した場合には、そのプログラムを停止させる必要がある。そこでスーパーバイザ20(システム状態監視部22)は、動作試験を監視し不具合発生時に、フリーズしたプログラムおよびこれと連携する他のプログラムの実行を停止させる。
図7を参照してシステム状態監視部22による監視処理を説明する。システム状態監視部22は定期的に処理を行うものであり、インターバルタイマなどにより割り込みが発生
する(S401)と、割り込みハンドラとしてシステム状態監視部22が起動する(S402)。起動したシステム状態監視部22は、自ノード上で実行されている全てのオペレーティングシステムの状態を調査し(S403)、状態が変化しないシステムが存在するか判断する(S404)。状態が変化しないシステムが存在しない場合は、次の割り込みが発生するまでシステム状態監視部を休眠させる(S408)。
状態が変化しないシステムが存在する場合(S404−YES)は、プログラムがフリーズしたと判断し、他ノードで動作している連携プログラムの停止を、他ノードのシステム制御部へ要求する(S405)。また、システム制御部は、フリーズしたプログラムを停止し、停止理由をログとして記録する(S406)。
これにより連携するプログラム全ての実行が停止されるので、プロセッサコアに空きができる。そこで、実行できる動作試験プログラムがある場合にはそれを実行する(S407)。そして、次の割り込みが発生するまでシステム状態監視部を休眠させる(S408)。
このようにフリーズしたプログラムが発生した場合に連携するプログラムを全て停止させることで、プロセッサコアに空きを作り他の動作試験プログラムを実行できる。したがって、プログラムがフリーズした場合であってもテストを効率良く実行することができる。
<実施形態の作用・効果>
このように本実施形態におけるプログラムテストでは、実際のシステム運用時には1つの処理(複数のノード間で連携して行う処理)しか行わないシングルスレッド型のシステムであっても、複数のテストケースを並列して実行することで短時間にプログラムテストを実行できる。
また、実際のシステム運用時と同様のシングルスレッド型の動作環境を実現するために、デバイスアクセス競合をトリガとして連携するプログラムを一斉に中断および再開する。テストケースを構成する一部のプログラムのみが中断された場合には、プログラム間の実行タイミングがずれて実際のシステム運用時とは異なる動作となってしまうが、本実施形態によるテスト手法では連携するプログラムを一斉に中断するためこのような実行タイミングのずれなどが発生しなくなる。したがって、実際の動作環境と同様の条件下でテストが実行可能となり正確なテストが実現できる。
また、デバイス競合が発生した場合はそのデバイスが利用可能となるまでテストケースが完了できないため、テストの実行効率が悪くなる。しかし、デバイス競合が発生したテストケースの連携プログラムを全て中断することで、演算資源に空きを作り他のテストケースを実行可能となる。つまり、より効率的にテストプログラムを実行可能である。
また、テストケースを構成する一部のプログラムをフリーズした場合に連携するプログラムを全て停止させることで、他のテストケースを実行可能となる。これにより、プログラムがフリーズして応答しなくなった場合であっても、効率良くテストを実行することができる。
N1〜N5 ノード
10 ハードウェア
11〜14 プロセッサコア
20 スーパーバイザ
21 連携部
22 システム状態監視部
23 デバイス状態管理部
31〜33 システム制御部

Claims (6)

  1. マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
    複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、当該システム内で複数並列に実行し、
    あるノードで実行中のプログラムにデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する
    ことを特徴とするプログラム検査方法。
  2. ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を前記システム内で実行する
    ことを特徴とする請求項1に記載のプログラム検査方法。
  3. 前記複数のプログラムが正常に動作しているかを監視し、
    あるノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する
    ことを特徴とする請求項1又は2に記載のプログラム検査方法。
  4. マルチコアプロセッサを有する複数のノードから構成され、当該複数のノードにおいて実行される複数のプログラムからなる動作試験を並列に実行するマルチコアシステムであって、
    当該マルチコアシステムを構成する各ノードが、
    ノードに接続されるデバイスへのアクセスを管理する管理部と、
    動作試験を構成するプログラムにおいてデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを中断させる要求を通知する連携部と、
    を備えることを特徴とするマルチコアシステム。
  5. ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を実行する
    ことを特徴とする請求項4に記載のマルチコアシステム。
  6. 前記複数のプログラムが正常に動作しているかを監視する監視部をさらに有し、
    前記連携部は、自ノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを停止させる要求を通知する
    ことを特徴とする請求項4又は5に記載のマルチコアシステム。
JP2009032691A 2009-02-16 2009-02-16 プログラム検査方法 Expired - Fee Related JP5299681B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009032691A JP5299681B2 (ja) 2009-02-16 2009-02-16 プログラム検査方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009032691A JP5299681B2 (ja) 2009-02-16 2009-02-16 プログラム検査方法

Publications (2)

Publication Number Publication Date
JP2010191522A JP2010191522A (ja) 2010-09-02
JP5299681B2 true JP5299681B2 (ja) 2013-09-25

Family

ID=42817533

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009032691A Expired - Fee Related JP5299681B2 (ja) 2009-02-16 2009-02-16 プログラム検査方法

Country Status (1)

Country Link
JP (1) JP5299681B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2755138B1 (en) * 2013-01-11 2018-11-28 Fujitsu Limited Testing implementation parameters of a computer program in a distributed environment

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03204735A (ja) * 1990-01-05 1991-09-06 Hitachi Ltd 競合動作試験方式
FR2809204B1 (fr) * 2000-05-17 2003-09-19 Bull Sa Interface applicative multiprosseur, ne necessitant pas l'utilisation d'un systeme d'exploitation multiprocesseur
JP2003099285A (ja) * 2001-09-25 2003-04-04 Toshiba Corp 機能競合に関するテストケース生成方法とその装置、そのためのプログラム
US7849362B2 (en) * 2005-12-09 2010-12-07 International Business Machines Corporation Method and system of coherent design verification of inter-cluster interactions

Also Published As

Publication number Publication date
JP2010191522A (ja) 2010-09-02

Similar Documents

Publication Publication Date Title
US10230608B2 (en) RPS support for NFV by system call bypass
JP5726340B2 (ja) プロセッサシステム
US20180150359A1 (en) Electronic apparatus, restarting method, and non-transitory recording medium
JP2014527249A5 (ja)
WO2007080931A1 (ja) デバッグ支援装置及びデバッグ処理方法をコンピュータに実行させるためのプログラム
US11099884B2 (en) Dynamic control of halt polling based on receiving a monitoring instruction executed by a guest
US10459771B2 (en) Lightweight thread synchronization using shared memory state
US9910717B2 (en) Synchronization method
US9367349B2 (en) Multi-core system and scheduling method
US10437308B2 (en) Predictive virtual machine halt
US11061840B2 (en) Managing network interface controller-generated interrupts
US11061730B2 (en) Efficient scheduling for hyper-threaded CPUs using memory monitoring
US20130132708A1 (en) Multi-core processor system, computer product, and control method
EP3036629B1 (en) Handling time intensive instructions
US11243800B2 (en) Efficient virtual machine memory monitoring with hyper-threading
JP5299681B2 (ja) プログラム検査方法
CN115576734B (zh) 一种多核异构日志存储方法和系统
JP5557612B2 (ja) 計算機及び転送プログラム
KR20130039479A (ko) 스레드 프로그레스 트래킹 방법 및 장치
JP5676664B2 (ja) リソース管理装置、リソースの管理方法、及びプログラム
WO2018003560A1 (ja) 電子制御装置
US20240134669A1 (en) Paravirtual pause loops in guest user space
US20180060097A1 (en) Hyper-threading based host-guest communication
US11947486B2 (en) Electronic computing device having improved computing efficiency
WO2013057769A1 (ja) 情報処理装置、情報処理装置の制御方法および制御プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130425

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130507

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20130603

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130605

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20130603

LAPS Cancellation because of no payment of annual fees