(57)【特許請求の範囲】
【請求項１】
複数のプロセッサによりタスクを処理するマルチプロセッサシステムにおいて、
１つ又は複数の各前記プロセッサを搭載するカードと、
前記カードを相互に接続するバスとを備え、
リソースの排他制御を実行中のプロセッサの存在の有無を示す排他制御フラグと、
前記カード毎に、排他制御要求の失敗がこれまでに発生したかどうかを示す失敗フラグと、
前記カード毎に、排他制御要求に失敗したために再発行された排他制御要求がこれまでに成功したことがあるかを示す成功フラグを備え、
各前記カードから出力される排他制御要求を、前記バスを介して他の前記カードが受け取り、
前記排他制御フラグが解除されている場合であって、
全ての前記カードについて前記失敗フラグが設定されていない場合、
或いは前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合に、
前記排他制御フラグを設定して前記排他制御要求に対する排他制御を行うことを特徴とするマルチプロセッサシステム。
【請求項２】
各前記カードは、
前記排他制御フラグが解除されている場合であって、前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合、
前記排他制御要求を発行したカード以外の全てのカードについて、前記失敗フラグと前記成功フラグの双方が設定されているかどうかのリセット条件を判別し、
前記リセット条件が満たされる場合には、前記全てのカードについて、前記失敗フラグと前記成功フラグを解除するリセットを行い、
前記リセット条件が満たされない場合には、前記排他制御要求を発行したカードの前記成功フラグを設定する
ことを特徴とする請求項１に記載のマルチプロセッサシステム。
【請求項３】
各前記カードは、
前記排他制御要求を受け取った場合において、
前記排他制御フラグが既に設定されている場合、
或いは前記排他制御フラグが解除されており、かつ前記排他制御要求を発行したカードの前記失敗フラグが解除されている場合に、
前記排他制御要求を発行したカードの前記失敗フラグを設定することを特徴とする請求項１又は請求項２に記載のマルチプロセッサシステム。
【請求項４】
複数のプロセッサによりタスクを処理するマルチプロセッサシステムの排他制御方法において、
１つ又は複数の各前記プロセッサを搭載するカードを備え、
各前記カードをバスにより相互に接続し、
リソースの排他制御を実行中のプロセッサの存在の有無を示す排他制御フラグを制御するステップと、
前記カード毎に、排他制御要求の失敗がこれまでに発生したかどうかを示す失敗フラグを制御するステップと、
前記カード毎に、排他制御要求に失敗したために再発行された排他制御要求がこれまでに成功したことがあるかを示す成功フラグを制御するステップを備え、
各前記カードから出力される排他制御要求を、前記バスを介して他の前記カードが受け取り、
前記排他制御フラグが解除されている場合であって、
全ての前記カードについて前記失敗フラグが設定されていない場合、
或いは前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合に、
前記排他制御フラグを設定して前記排他制御要求に対する排他制御を行うステップを備えることを特徴とすることを特徴とする排他制御方法。
【請求項５】
各前記カードにおいて、
前記排他制御フラグが解除されている場合であって、前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合、
前記排他制御要求を発行したカード以外の全てのカードについて、前記失敗フラグと前記成功フラグの双方が設定されているかどうかのリセット条件を判別し、
前記リセット条件が満たされる場合には、前記全てのカードについて、前記失敗フラグと前記成功フラグを解除するリセットを行い、
前記リセット条件が満たされない場合には、前記排他制御要求を発行したカードの前記成功フラグを設定するステップを備えることを特徴とする請求項４に記載の排他制御方法。
【請求項６】
前記カードにおいて、
前記排他制御要求を受け取った場合において、
前記排他制御フラグが既に設定されている場合、
或いは前記排他制御フラグが解除されており、かつ前記排他制御要求を発行したカードの前記失敗フラグが解除されている場合に、
前記排他制御要求を発行したカードの前記失敗フラグを設定するステップを備えることを特徴とする請求項４又は請求項５に記載の排他制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、マルチプロセッサシステムに関し、特に複数のＣＰＵの排他制御を処理するマルチプロセッサシステムとその排他制御方法に関する。
【０００２】
【従来の技術】
従来のマルチプロセッサシステムの排他制御の調停においては、現在排他制御が実行中かどうかを示すリソースロックフラグを用いるものであった。
【０００３】
このリソースロックフラグは、システムを構成する各プロセッサにおいて排他制御を実行するプロセッサがある場合にＯＮ（‘１’）、そうでない場合にＯＦＦ（‘０’）を示す。
【０００４】
各プロセッサは、このリソースロックフラグを排他制御の実行前に必ずチェックし、排他制御中の他のプロセッサが存在しない場合であるリソースロックフラグがＯＦＦを示す場合に限り、システムは当該プロセッサにおける排他制御を許可する。
【０００５】
もし、ここで排他制御実行中の他のプロセッサが存在することにより、リソースロックフラグがＯＮを示す場合においては、その時点では当該プロセッサに排他制御が許可されず、他のプロセッサにおける排他制御が終了しリソースロックフラグがＯＦＦに変わるまで実行を待機する。
【０００６】
以上のようにして、従来のマルチプロセッサシステムでは、システムを構成する各プロセッサにおける排他制御を調停していた。
【０００７】
また、こうした従来のマルチプロセッサシステムの構造を説明する。
【０００８】
従来のマルチプロセッサシステムは、例えば、それぞれに１個あるいは複数個のプロセッサを備えるＣＰＵ（やカード等）を複数備え、この複数の各ＣＰＵ等の間でタスクを並行して処理したり、排他制御の調停等を行う。
【０００９】
各ＣＰＵの間には、排他制御等に必要な情報を送受するためのバス等の信号線を接続し、このバス等を用いることにより、各ＣＰＵは上記のリソースロックフラグのデータ等を参照する。
【００１０】
また、こうした従来のマルチプロセッサシステムには、各ＣＰＵによるこのバスへの排他制御の要求出力を、アクセスタイムの向上等のために、調停を行う事なしに各ＣＰＵが任意のタイミングで出力し、当該タイミングで全てのＣＰＵがその要求出力を受け取り、全ＣＰＵ同一の調停論理により要求処理順序を決定するという分散調停方式を採用するものもある。
【００１１】
【発明が解決しようとする課題】
上述したように従来のマルチプロセッサシステムでは、以下に述べるような問題点があった。
【００１２】
従来では、リソースロックフラグによる、単に現在排他制御の実行中かどうかを示す情報のみに基づき、複数のプロセッサ間での排他制御を調停するものであった。
【００１３】
このように、排他制御の実行許可の待機中であるＣＰＵ等の情報を参照していないため、排他制御の調停が単に排他制御要求の受付順等により実行されるのみであり、排他制御が調停されるＣＰＵが偏ることがあるという問題があった。更に、ある特定のプロセッサにおいて、その排他制御の実行のためのリソースロックフラグのチェック時に、常に他のプロセッサが排他制御中となることにより、いつまで待機しても実行が許可されずにプロセッサタイムアウトになることがあった。
【００１４】
本発明の第１の目的は、上記従来技術の欠点を解決し、効率的に排他制御を調停することにより、タイムアウト等のシステムの処理に支障をきたす事態の発生を防止するマルチプロセッサシステムとその排他制御方法を提供することである。
【００１５】
本発明の第２の目的は、上記従来技術の欠点を解決し、排他制御の調停先のそれぞれにおける排他制御の失敗の履歴とその失敗の解消の履歴を示すフラグを新たに備えるという簡易な構成により、効率的に排他制御を調停しタイムアウトの発生を防止するマルチプロセッサシステムとその排他制御方法を提供することである。
【００１６】
【課題を解決するための手段】
上記目的を達成するため本発明は、複数のプロセッサによりタスクを処理するマルチプロセッサシステムにおいて、１つ又は複数の各前記プロセッサを搭載するカードと、前記カードを相互に接続するバスとを備え、前記カード毎に、リソースの排他制御を実行中のプロセッサの存在の有無を示す排他制御フラグと、前記カードからの排他制御要求の失敗がこれまでに発生したかどうかを示す失敗フラグと、前記カードからの排他制御要求に失敗したために再発行された排他制御要求がこれまでに成功したことがあるかを示す成功フラグを備え、各前記カードから出力される排他制御要求を、前記バスを介して他の前記カードが受け取り、前記排他制御フラグが解除されている場合であって、全ての前記カードについて前記失敗フラグが設定されていない場合、或いは前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合に、前記排他制御フラグを設定して前記排他制御要求に対する排他制御を行うことを特徴とする。
【００１７】
請求項２の本発明のマルチプロセッサシステムは、各前記カードは、前記排他制御フラグが解除されている場合であって、前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合、前記排他制御要求を発行したカード以外の全てのカードについて、前記失敗フラグと前記成功フラグの双方が設定されているかどうかのリセット条件を判別し、前記リセット条件が満たされる場合には、前記全てのカードについて、前記失敗フラグと前記成功フラグを解除するリセットを行い、前記リセット条件が満たされない場合には、前記排他制御要求を発行したカードの前記成功フラグを設定することを特徴とする。
【００１８】
請求項３の本発明のマルチプロセッサは、各前記カードは、前記排他制御要求を受け取った場合において、前記排他制御フラグが既に設定されている場合、或いは前記排他制御フラグが解除されており、かつ前記排他制御要求を発行したカードの前記失敗フラグが解除されている場合に、前記排他制御要求を発行したカードの前記失敗フラグを設定することを特徴とする。
【００１９】
請求項４の本発明は、複数のプロセッサによりタスクを処理するマルチプロセッサシステムの排他制御方法において、１つ又は複数の各前記プロセッサを搭載するカードを備え、各前記カードをバスにより相互に接続し、リソースの排他制御を実行中のプロセッサの存在の有無を示す排他制御フラグを制御するステップと、前記カード毎に、排他制御要求の失敗がこれまでに発生したかどうかを示す失敗フラグを制御するステップと、前記カード毎に、排他制御要求に失敗したために再発行された排他制御要求がこれまでに成功したことがあるかを示す成功フラグを制御するステップを備え、各前記カードから出力される排他制御要求を、前記バスを介して他の前記カードが受け取り、前記排他制御フラグが解除されている場合であって、全ての前記カードについて前記失敗フラグが設定されていない場合、或いは前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合に、前記排他制御フラグを設定して前記排他制御要求に対する排他制御を行うステップを備えることを特徴とする。
【００２０】
請求項５の本発明の排他制御方法は、各前記カードにおいて、前記排他制御フラグが解除されている場合であって、前記排他制御要求を発行したカードに、前記失敗フラグが設定され、かつ前記成功フラグが設定されていない場合、前記排他制御要求を発行したカード以外の全てのカードについて、前記失敗フラグと前記成功フラグの双方が設定されているかどうかのリセット条件を判別し、前記リセット条件が満たされる場合には、前記全てのカードについて、前記失敗フラグと前記成功フラグを解除するリセットを行い、前記リセット条件が満たされない場合には、前記排他制御要求を発行したカードの前記成功フラグを設定するステップを備えることを特徴とする。
【００２１】
請求項６の本発明の排他制御方法は、前記カードにおいて、前記排他制御要求を受け取った場合において、前記排他制御フラグが既に設定されている場合、或いは前記排他制御フラグが解除されており、かつ前記排他制御要求を発行したカードの前記失敗フラグが解除されている場合に、前記排他制御要求を発行したカードの前記失敗フラグを設定するステップを備えることを特徴とする。
【００２２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【００２３】
図１は、本発明の第１の実施の形態によるマルチプロセッサシステム１の構成の一例を示すブロック図であり、複数のカード１００（ＣＰＵその他の電子部品を搭載する電子基板）にプロセッサを搭載し、そのカード１００間を１：ｎの片方向バスで接続している。図１の例では、本発明を説明するにあたり簡単化のため各カード１００に搭載されるプロセッサ数を１個としたが、複数個でもかまわない。また、図１の例では（第０から第３までの）４個のカードを用いているが、カード数は２枚以上ならば何枚でもかまわない。
【００２４】
図１を参照すると、本実施の形態によるマルチプロセッサシステム１の各カード１００には、プロセッサであるバス要求発行部１０、バス要求制御部２０、要求受付調停部３０、リソースロック制御部４０、要求制御部５０、リソースロックの成功を通知するためのリソースロック成功通知線６０、リソースロックの失敗を通知するためのリソースロック失敗通知線７０を備えている。
【００２５】
バス要求発行部１０は、各カード１００のそれぞれにおける（第０から第３の）プロセッサであり、共用のメモリ領域へのアクセス要求や、その他の同時には装置内で唯一のプロセッサのみがアクセス可能である領域（以後、これを共有領域と呼ぶ）にアクセスするための要求を発行する。
【００２６】
特に共有領域へのアクセス要求においては、他のプロセッサとの共有領域アクセスの排他制御を実現するために、事前にリソースロック要求を発行することにより排他制御を開始し、その終了後には共有領域アクセス終了を宣言し排他制御を解除するためのリソースアンロック要求を発行する。なお、以後この一連のリソースロック要求からリソースアンロック要求までの処理を、リソースロックシーケンスと呼ぶ事にする。
【００２７】
バス要求制御部２０は、各カード１００内のプロセッサから受け付けた、各種要求のバスへの発行を行う。
【００２８】
特にリソースロック要求の発行時においては、他のプロセッサが共有領域アクセス中のためにリソースロック失敗が発生することがあり、この場合にバス要求制御部２０は、リソースロック要求の再発行を行う。
【００２９】
ここで、リソースロック失敗とは、リソースロック制御部４０にて共有領域をアクセス中のプロセッサが存在する事が確認されたため、排他制御により共有領域アクセスが認められない状態であり、逆にリソースロック成功とは、共有領域をアクセス中のプロセッサが存在しない事が確認され共有領域アクセスが許可された状態である。
【００３０】
バス８１、８２、８３、８４は、各カード１００間を接続する１：ｎの片方向バスである。このバスは出力として使用する信号線と入力として使用する信号線が各カード１００毎に固有に定められている。
【００３１】
自カードが出力するための信号線には入出力バッファを用い、自カードが出力した要求は他カードが受け取るのと同時に（同様にして）自カードでも受け取る。他カードが出力する信号線には入力専用バッファを用いて、その他カードが出力した要求を受け取る。
【００３２】
それぞれのカードのバス要求発行部１０は、自カードの出力専用信号線２１（又は２２、２３、２４）を使って要求を発行するが、この発行にあたって出力許可のための調停は行わず、各カードが任意のタイミングで要求を発行する。
【００３３】
要求受付調停部３０は、全てのカードにおいて、他のカードや自らのカードが発行した各種要求をその発信と同時にバスから受け付け、特に複数カードからの要求を同時に受け付けた際には全カード共通の調停論理により要求処理順を決定し、全く同じ順序で自カード内の要求制御部５０等へ受け渡す。
【００３４】
リソースロック制御部４０は、全てのカードにおいて、各カード内の要求受付調停部３０が受け付けた要求を、全く同じタイミングで同順序で受け取り、同等の内部制御を実行する。
【００３５】
リソースロック制御部４０は、共有領域アクセスのプロセッサ間排他制御を実現するための機能を有し、リソースロック要求を受け付けたならばリソースロックフラグを参照して他プロセッサの共有領域アクセス状況をチェックし、その要求のリソースロック成功又は失敗を判断する。その要求が自カード出力のものである場合は、自カード内のプロセッサ（バス要求発行部１０）及びバス要求制御部２０に対して成功通知線６０、又は失敗通知線７０を介してリソースロック要求の結果を通知する。
【００３６】
要求制御部５０は、リソースロック要求以外の制御部であり、通常のメモリアクセス要求等を実行する。
【００３７】
図５は、本実施の形態のリソースロック制御部４０の構成を説明するためのブロック図である。
【００３８】
図５を参照すると、本実施の形態のリソースロック制御部４０は、このリソースロック制御部４０の処理を制御する制御回路４４を備え、制御回路４４がリソースロックフラグ４１、失敗フラグ４２、成功フラグ４３のデータを参照し、要求受付調停部３０から送られる要求に従い、プロセッサやバス要求制御部２０への通知や、各種フラグのデータの変更等を指示し実行する。
【００３９】
リソースロックフラグ４１は、共有領域アクセス中の（排他制御の実行中の）プロセッサが存在するか否かを示すフラグである。リソースロックフラグ４１は、カード１００毎に個別のデータが記録されるのではなく、全カードにおいて同じ状態を示すものである。
【００４０】
図６は、本実施の形態のリソースロックフラグ４１の状態値とその意味を示す図である。
【００４１】
リソースロックフラグ４１は、現在排他制御を行うプロセッサが存在しない場合に‘０’の値を示し、現在排他制御を行うプロセッサが存在する場合には‘１’の値を示す。
【００４２】
失敗フラグ４２は、各カードのそれぞれにおいてこれまでにリソースロックに失敗したことがあるかどうかを示すフラグである。本実施の形態の失敗フラグ４２では、（第０から第３までの４枚の）各カード毎にその失敗の発生の有無を示すビットを備えて、その各ビットが‘０’（まだ、リソースロックに失敗したことがない場合）又は、‘１’（既に、リソースロックに失敗したことがある場合）の値を示す。以後、失敗フラグ４２の各ビットの値を、各カードの番号“ｎ”（ｎ＝０、１、２、３）に対応させて“ＳＴＶ（ｎ）”により示す。
【００４３】
成功フラグ４３は、各カードのそれぞれにおいてこれまでに、リソースロックに失敗したために再発行されたリソースロック要求に成功したことがあるかを示すフラグである。本実施の形態の成功フラグ４３では、（第０から第３までの４枚の）各カード毎にその再発行されたリソースロック要求の成功の発生の有無を示すビットを備えて、その各ビットが‘０’（まだ、再発行のリソースロックに成功したことがない場合）又は、‘１’（既に、再発行のリソースロックに成功したことがある場合）の値を示す。以後、成功フラグ４３の各ビットの値を、各カードの番号“ｎ”（ｎ＝０、１、２、３）に対応させて“ＳＴＦ（ｎ）”により示す。
【００４４】
リソースロックフラグ４１及び失敗フラグ４２と成功フラグ４３の各ビットの値は、全カードで同じ状態が認識される。つまり、各フラグの値を更新するデータや命令はバス８０を介して全カードに共通に通知され、各カードはバス８０から通知される情報を元に同一のアルゴリズム（調停論理等）に基づき判定することで、同一の決定が得られるのである。これにより各カードでは、各ビットへの‘１’をセット（ＯＮにする、設定する等）したり、‘０’にリセット（ＯＦＦにする、解除する等）する処理を同時に実行することができる。
【００４５】
また、リソースロックに失敗した全てのカードが、その後リソースロック要求の再発行によりリソースロックに成功した場合には、失敗フラグ４２と成功フラグ４３の全カードに対応するビットを‘０’にリセットする。
【００４６】
つまり、失敗フラグ４２と成功フラグ４３の各カードに対応するビットの値が、共に‘１’か、共に‘０’である場合（ＳＴＶ（ｎ）＝ＳＴＦ（ｎ）、（ｎ＝０、１、２、３）の場合）には、ＳＴＶ（ｎ）＝０、ＳＴＦ（ｎ）＝０、（ｎ＝０、１、２、３）として各フラグのビットを‘０’にリセットする。
【００４７】
またこのようにして、失敗フラグ４２及び成功フラグ４３の全ビットを同時に‘０’に初期化する「リセット」が実行されるまでは、各フラグの一旦‘１’がセットされたビットはそのまま‘１’の値を保持する。
【００４８】
このように、失敗フラグ４２及び成功フラグ４３は、（前回フラグをリセットした以後）現在までに、各カードにおいて指定された状態が発生したかどうかを示すのであり、現時点における状態を示すものではない。
【００４９】
つまり、失敗フラグ４２は、一度リソースロックが失敗して‘１’がセットされた後は、再発行されたリソースロック要求が成功しても‘０’に戻るのではない。同様に、成功フラグ４３は、リソースロックの失敗の後に、再発行されたリソースロック要求が成功して‘１’がセットされた後は、再び新たなリソースロックの失敗が発生しても‘０’に戻るのではない。
【００５０】
図７は、本実施の形態の失敗フラグ４２と成功フラグ４３とにおける同じカードに対応するビットの値の組と、その状態の説明を示す図である。
【００５１】
図７を参照すると、失敗フラグ４２と成功フラグ４３とにおける同じカードに対応するビットの値は、これまでに（前回リセットした以後）当該カードのリソースロック要求が失敗していない場合では、共に‘０’の値を示す。そして、当該カードのリソースロック要求に失敗が発生すると、失敗フラグ４２の当該カードに対応するビットの値が‘１’にセットされ、また、成功フラグ４３の当該カードに対応するビットの値は‘０’の状態のままであり、その後再発行されるリソースロック要求に成功するまで変更されない。そして、このリソースロック要求の失敗の後、再発行されたリソースロック要求に成功した場合には、成功フラグ４３の当該カードに対応するビットの値も‘１’にセットされる。
【００５２】
そして、失敗フラグ４２と成功フラグ４３との、各カードのそれぞれに対応するビットの組が共に‘１’を示すか、共に‘０’を示すかのいずれかのみである場合（つまり、リソースロック要求の失敗の後、再発行されたリソースロック要求に成功していないカードの無い場合）においては、各フラグの全てのカードに対応するビットを‘０’にリセットし初期状態に戻す。
【００５３】
リソースロック制御部制御回路４４は、リソースロックフラグ４１、失敗フラグ４２、成功フラグ４３及び要求受付調停部３０よりの要求を入力として、リソースロックの成功・失敗の判断及びその通知、リソースロックフラグ４１、失敗フラグ４２、成功フラグ４３の状態制御を行う。
【００５４】
従来のリソースロック制御部４０では単にリソースロックフラグ４１のみを備える構成であったため、複数のプロセッサ間でのリソースロック要求の競合が発生した場合には、要求受付調停部３０の調停具合によってはその競合が解消されないこともあった。例えば、特定のカードのリソースロック要求がリソースロックフラグ４１を参照する場合に常に他のプロセッサによる共有領域アクセスシーケンス中となり、リソースロック要求の再発行がプロセッサタイムアウトまで続けられることも発生していた。
【００５５】
本実施の形態のマルチプロセッサシステム１は、新規に失敗フラグ４２、成功フラグ４３を用意する事により、リソースロック要求競合時にリソースロックを各カードや各プロセッサに均等に行えるようにし、プロセッサタイムアウトの発生を防ぐことができる。
【００５６】
次に、本実施の形態のマルチプロセッサシステム１の動作を説明する。
【００５７】
図２は、本実施の形態のマルチプロセッサシステム１における各プロセッサのリソースロックの処理を説明するためのフローチャートである。ここでは、マルチプロセッサシステム１内に備えるある１つのプロセッサ（例えば、第１プロセッサ）により実行されるリソースロックを説明する。
【００５８】
まず、リソースロックを行うプロセッサ１０は、共有領域のアクセス実行前にリソースロック要求をバス要求制御部２０に発行する（ステップ２０１）。そして、当該プロセッサ１０を格納したカード１００内のリソースロック制御部４０からの、リソースロック成功通知の通知を待機する。
【００５９】
ここで、リソースロックに失敗した場合には、バス要求制御部２０からバスへのリソースロック要求の再発行が実行されるが、プロセッサ１０に通知する必要は必ずしもないため、失敗通知はバス要求制御部２０のみに通知されるようにしてもよい。
【００６０】
リソースロック成功通知を受け付けた場合に（ステップ２０２）、当該プロセッサ１０は必要な共有領域へのアクセス要求を実行し（ステップ２０３）、その共有領域をアクセスする全ての処理を終了した後に、リソースロックアンロック要求を発行することにより（ステップ２０４）このリソースロックを終了する。
【００６１】
図３は、本実施の形態のバス要求制御部２０のバス要求発行制御を説明するためのフローチャートである。
【００６２】
図３を参照すると、本実施の形態のバス要求制御部２０は、プロセッサ１０からの各種要求の発行を待機し（ステップ３０１）、プロセッサ１０から要求を受け付けた場合には、その要求をバス８０へ発行する（ステップ３０２）。これは、例えば第０カードからの要求を発行する場合では、バス要求制御部２０はバス８０内の第０カードから出力するための信号線である信号線８１から出力するのである。
【００６３】
そして、その要求がリソースロック要求であるか否かをチェックし（ステップ３０３）、リソースロック要求でない場合には、プロセッサ１０からの次の要求の発行を待機する始めの状態に戻る。
【００６４】
リソースロック要求である場合には、リソースロック制御部４０からのリソースロック成功通知又は失敗通知を待機し、リソースロック成功通知を受け付けた場合には、プロセッサ１０からの次の要求の発行を待機する始めの状態に戻る（ステップ３０４）。
【００６５】
リソースロック失敗通知を受け付けた場合には（ステップ３０５）、同じリソースロック要求を再発行し（ステップ３０６）、再びリソースロック制御部４０からのリソースロック成功通知又は失敗通知を待機する。ここでの、リソースロック要求を再発行してその成功通知又は失敗通知を待機する処理は、成功通知を受け付けるまで同様にして繰り返し実行する。
【００６６】
図４は、本実施の形態の要求受付調停部３０による調停論理の一例を示す図である。
【００６７】
要求受付調停部３０は、同時に複数のカードからの要求を受け付けた場合に、要求を実行するカードを選択しそれを実行する。その実行するカードの選択方法を規定する調停論理は、特別な制限や条件を必要とするのではなく、各カードのそれぞれの要求受付調停部３０において同一の調停論理が設定されることにより同一の選択が実行されるものであればよい。それは、本実施の形態のマルチプロセッサシステム１では、たとえ要求受付調停部３０の段階において実行するカードの選択に偏りがあるとしても、実際に実行するカードは更にリソースロック制御部４０において適切に調整され、再要求中の（要求が失敗したために要求を再発行している）カードを優先して実行するため、いつまでも要求が実行されずにタイムアウトが発生する等の障害が大きく軽減されるのである。
【００６８】
例えば、図４の例の調停論理では、同時に複数のカードからの要求を受け付けた場合に、常にカード番号の小さいカードを優先して処理するという調停論理を採用している。これは、大きく偏りのある調停論理の例であり、同時に複数のカードからの要求が重なった場合に、第０カードにおいては常に直ちに実行されるのに対し、一方第３カードにおいては常にその実行を待機することになる。
【００６９】
しかし、この図４の例のような単純な調停論理を行う回路は、各カードの調停が均等になるように工夫を施した回路よりも、遥かに簡単な回路構成により実現できその作成が容易である。
【００７０】
各カードのバス要求制御部２０から出力される各種の要求は、バス８０の各カードに対応する信号線を介して全カードの要求受付調停部３０に同時に入力されることにより、同一の調停が実行され、同一のタイミングでそれぞれのカードの要求受付調停部３０から、リソースロック制御部４０及びその他の要求を制御する要求制御部５０に転送される。
【００７１】
図８は、要求受付調停部３０がリソースロック制御部４０に送る転送要求のデータ形式の一例を示す図である。
【００７２】
要求バリッド３１は、１ビットのデータであり、‘１’の時に要求が有効となり‘０’の時には無効と判断される。
【００７３】
要求コマンド３２は、要求する内容を示す８ビットのデータであり、例えば（２進法で）‘１１１１１１１０’の場合リソースロック要求である事を示し、（２進法で）‘１１１１１１１１’の場合リソースアンロック要求である事を示し、その他の場合である先頭から‘１’が７つ連続する以外のコードを、メモリやデバイスのアクセス要求等に割当てる等の方式が可能である。
【００７４】
要求ソースコード３３は、この要求を発信したカードを示すためのデータであり、本実施例においては４個のカードを用いているため、２ビットのデータを備えればその各カードの番号を示すことができる。
【００７５】
図９は、本実施の形態のリソースロック制御部４０の制御を説明するためのフローチャートである。
【００７６】
図９を参照すると、本実施の形態の各カード１００におけるリソースロック制御部４０は、まず、要求受付調停部３０から受け付けた要求がリソースロック要求であるかどうかをチェックし（ステップ９０１）、そうでなければリソースアンロック要求であるかをチェックする（ステップ９０２）。
【００７７】
リソースロック要求でもリソースアンロック要求でもない場合には、その要求は要求制御部５０により処理される要求であるため、リソースロック制御部４０においてはその処理を終了する。また、リソースアンロック要求である場合には、この要求は共有領域アクセス終了後にそのリソースのロックを解放するために発行される要求であり、‘１’であるリソースロックフラグ４１を‘０’にリセットして（ステップ９０３）終了する。
【００７８】
リソースロック要求である場合には、リソースロックフラグ４１をチェックし、現在既にリソースがロックされているかどうかをチェックする（ステップ９０４）。
【００７９】
もし、既にリソースがロックされている場合（リソースロックフラグ４１が‘１’の場合）ならば、リソースロック失敗であり、失敗フラグ４２の要求発行元カードに対応するビットをチェックし（ステップ９０５）、もし‘０’の場合には‘１’にセットし、リソースロック失敗が当該カードに発生したことを記録する。
【００８０】
これにより、当該リソースロック要求を発行したカード以外のリソースロック制御部４０は処理を終了し（ステップ９０７）、一方、当該リソースロック要求を発行したカード内のリソースロック制御部４０においては、自カードのバス要求制御部２０にリソースロック失敗を通知した後に（ステップ９０８）処理を終了する。
【００８１】
ステップ９０４において、まだリソースがロックされていない場合（リソースロックフラグ４１が‘０’の場合）ならば、全カードの失敗フラグをチェックし、リソースロックの失敗が記録されていない全て‘０’である場合には、当該リソースロックの実行に何ら問題は無いため、リソースロックを開始してリソースロックフラグ４１に‘１’をセットする（ステップ９１５）。
【００８２】
これにより、当該リソースロック要求を発行したカード以外のリソースロック制御部４０は処理を終了し（ステップ９１６）、一方、当該リソースロック要求を発行したカード内のリソースロック制御部４０においては、自カードのバス要求制御部２０にリソースロック成功を通知した後に（ステップ９１７）処理を終了する。
【００８３】
ステップ９０９において、失敗フラグにリソースロックの失敗が記録されているカードが存在する場合（失敗フラグに‘１’を示すビットが１つでもある場合）には、各カードにおける優先度を参照し、当該リソースロックを実行するかどうかを判定する。
【００８４】
つまりここで、リソースロックが失敗した後にまだその再要求に成功していないカード（失敗フラグが‘１’かつ成功フラグが‘０’のカード）を優先して実行し、またそうでないカードからのリソースロック要求を実行しないように制御するのである。
【００８５】
また、この場合においては、失敗フラグが‘１’かつ成功フラグが‘０’のカードは、少なくとも１つ以上は存在しているため、この条件を満たすカードのみを優先しても無限ループは発生しない。
【００８６】
その理由は、失敗フラグ４２に‘１’を示すビットが１つ以上存在し（ステップ９０９）、更に、失敗フラグ４２に‘１’を示すカードの全てが、成功フラグ４３に‘１’の値を示すことはないからである。
【００８７】
つまり、図９のフローチャート中で成功フラグ４３のビットに‘１’がセットされるのは、ステップ９１４のみであり、そのステップの時点で両フラグの‘１’を示すカードが全て共通する上記の事態が発生しうる場合には、１つ前のステップ９１２においてこれを回避し、双方のフラグの全ビットを‘０’とするリセット（ステップ９１３）を実行するのである。
【００８８】
このリソースロックを実行するかどうかの判定処理は、まず失敗フラグ４２の要求発行元のカードに対応するビットをチェックし（ステップ９１０）、もし、まだ当該カードにおけるリソースロックの失敗が記録されていない場合（失敗フラグ４２が‘０’の場合）には、リソースロック失敗と判定しステップ９０６の処理へ移行する。
【００８９】
もし、既に当該カードにおけるリソースロックの失敗が記録されている場合（失敗フラグ４２が‘１’の場合）には、更に成功フラグ４３の要求発行元のカードに対応するビットをチェックし（ステップ９１１）、もし、既に当該カードにおける再発行されたリソースロック要求の成功が記録されている場合（成功フラグ４３が‘１’の場合）には、リソースロック失敗と判定しステップ９０７の処理へ移行する。
【００９０】
もし、まだ当該カードにおける再発行されたリソースロック要求の成功が記録されていない場合（成功フラグ４３が‘０’の場合）には、当該カードは、失敗フラグが‘１’かつ成功フラグが‘０’である優先して実行するカードであるため、リソースロック成功と判定される。
【００９１】
この場合、ここで直ちに成功フラグ４３の当該カードに対応するビットに‘１’をセットするものとしてもよいが、図９の実施例では、まずリセットを実行する条件を満たしているかどうかをチェックする方式を採用している。この方式においては、‘１’をセットした直後にこれを‘０’にリセットする無駄な書き換え処理の発生を防止することができる。
【００９２】
このため、失敗フラグ４２と成功フラグ４３の（本リソースロック要求の発行元のカード以外に対応する）全てのビットをチェックし（ステップ９１２）、同じカードに対応するビット（ＳＴＶ（ｎ）、ＳＴＦ（ｎ））が、（０、０）か（１、１）のみである場合には、失敗フラグ４２と成功フラグ４３の全てのビットを‘０’にリセットする（ステップ９１３）。
【００９３】
また、そうでない場合には、リソースロックに失敗した後にその再要求に成功していない（１、０）の組み合わせのカードが（本リソースロック要求の発行元のカード以外に）存在する場合であり、フラグのリセットは実行しない。また、このためステップ９１１において実行しなかった、リソースロック要求の発行元のカードに対応する成功フラグ４３のビットへの‘１’のセットを実行する（ステップ９１４）。
【００９４】
そして、ステップ９１３とステップ９１４のいずれの場合も、次に９１５の処理へ移行し、当該カードにより要求されたリソースロックを実行する。
【００９５】
以上の処理は、全カード１００のリソースロック制御部４０において、同タイミングにより実行される。
【００９６】
図１０は、本実施の形態のリソースロック要求とリソースアンロック要求を処理する各カードのリソースロック制御部４０の動作を説明するためのタイミングチャートの一例である。
【００９７】
なお図１０のタイミングチャート中における要求受付調停部３０からの要求コマンドコードの“ＲＬＫ”はリソースロック要求を示し、“ＲＵＬＫ”はリソースアンロック要求を示す。また、要求受付調停部３０からの要求ソースコードの数字は、リソースロック要求及びリソースアンロック要求の発行元のカード番号を示す２進数表示のデータである。
【００９８】
また、図１０においては、リソースロックに関係する処理を説明する目的のため、その他のリソースロックに成功したカードからの共有メモリアクセス要求や他カードからの通常要求等による処理を省略している。
【００９９】
まず、本実施の形態のマルチプロセッサシステム１の各フラグのデータは、初期状態では、リソースロックフラグ４１及び失敗フラグ４２と成功フラグ４３の全てのビットが‘０’を示すものであり、また各カード１００において各フラグのデータは共通の値が認識される。
【０１００】
図１０の、１番目の処理である［Ｔ１］においては、この初期状態から開始し［Ｔ１−１］、まず第０カードからのリソースロック要求を受け付けている［Ｔ１−２］。
【０１０１】
これにより、各カードのリソースロック制御部４０は、リソースロック成功と判定しリソースロックフラグに‘１’をセットする［Ｔ１−２］。更に、要求の発行元である第０カードのリソースロック制御部４０では、リソースロック成功通知を生成し、これを第０カードの要求発行部１０（第０プロセッサ）及びバス要求制御部２０に通知する。
【０１０２】
なお、この時はまだリソースロック要求の競合状態ではないので失敗フラグ４２及び成功フラグ４３の状態遷移はない。
【０１０３】
［Ｔ１］においては、ここでの第０カードによるリソースロックがされた状態で、更にリソースロック要求を第１カード［Ｔ１−４］と第３カード［Ｔ１−５］から受け付けることにより、リソースロック要求の競合状態が発生することになる。
【０１０４】
この場合、リソースロックフラグが‘１’であるため、各カードのリソースロック制御部４０はリソースロック失敗と判断し、失敗フラグ４２のセット指示を第１カード［Ｔ１−４］及び第３カード［Ｔ１−５］のそれぞれに生成し、Ｔ１−５とＴ１−６においてそれぞれがセットされる。
【０１０５】
２番目の処理である［Ｔ２］においては、リソースをロックしていた第０カードによる共有領域等における処理が終了したため、まず第０カードがそのリソースロックを解放する［Ｔ２−１］。
【０１０６】
これは、第０カードからリソースアンロック要求が発行され、各カードによりこれが受け付けられることにより、リソースロックフラグは‘０’にリセットされリソースが解放される［Ｔ２−２］。
【０１０７】
この状態において、第０カードから更に新規のリソースロック要求が発行されている［Ｔ２−３］。しかし、（ｎ＝１、３）における（ＳＴＶ（ｎ）、ＳＴＦ（ｎ））が（１、０）を示しているため、第０カードによるリソースロック要求は実行しない。これは、ロックするリソース自体はリソースロックフラグが‘０’であり解放されているが、一方、現時点において第１カードと第３カードがリソースロックに失敗し再発行中であるため、これらのカードによる実行を優先するためである。
【０１０８】
これにより、各カードにおいて失敗フラグ４２の第０カードを示すビットに“１”をセットする指示が出され［Ｔ２−３］、これがセットされる［Ｔ２−４］。また、リソースロック要求の発行元の第０カード内では失敗通知が生成され通知される。
【０１０９】
また、第０カードは、Ｔ２−１におけるリソースロック要求においては、優先されるカードではなかったが、これにより失敗フラグ４２に“１”がセットされ、第１カードや第３カードと同様の優先するカードとなった。よって以後、リソースロックが解放されている時に、第０カードからリソースロック要求が再発行された場合には実行されることになる。
【０１１０】
続いて、第３カードからリソースロック要求の再発行を受けると［Ｔ２−５］、（ＳＴＶ（３）、ＳＴＦ（３））は（１、０）であり、この第３カードはリソースロック要求の再発行にまだ成功していない優先されるカードに該当するため、各カードのリソースロック制御部４０はこの再発行されたリソースロック要求を成功と判断し、成功フラグ４３の第３カードに対応するビットに‘１’をセットする指示が生成され［Ｔ２−５］、セットされる［Ｔ２−６］。また、第３カードでは、成功通知が生成される［Ｔ２−５］。
【０１１１】
３番目の［Ｔ３］では、まずＴ２−１と同様にして、リソースをロックしていた第３カードによる共有領域等における処理が終了したため、第３カードがそのリソースロックを解放する［Ｔ３−２］。
【０１１２】
これは、第３カードからリソースアンロック要求が発行され、各カードによりこれが受け付けられることにより、リソースロックフラグは‘０’にリセットされリソースが解放される［Ｔ３−１］。
【０１１３】
そして、Ｔ３−３において、Ｔ２−３と同様にして、一度リソースロックを実行した第３カードから新規のリソースロック要求を受け付けると、（ＳＴＶ（３）、ＳＴＦ（３））は（１、１）であり、これは、第３カードは以前にリソースロック要求競合の後にリソースロックに成功したことのあるカードであり、優先されるカードではなく、またこのカードの他に未だリソースロック競合に失敗した後にリソースロックに成功していない優先される他カードが存在する（存在しない場合は（０、０）としてリセットされている）のであるから、第３カード３はリソースロック失敗と判断される。ここで、既に第３カードに対応するビットの失敗フラグ４２及び成功フラグ４３には‘１’がセットされているのであるから、これら失敗フラグ４２及び成功フラグ４３の状態遷移はない。また、第３カード内には失敗通知が生成される。
【０１１４】
続いて、第０カードから、Ｔ２−３におけるリソースロック失敗のために再発行されたリソースロック要求を受け付けると、リソースロックフラグは‘０’であるため解放されており、（ＳＴＶ（０）、ＳＴＦ（０））は（１、０）であるため第０カードは優先するカードでありリソースロック成功と判断される。全カード内において成功フラグ４３の第０カードに対応するビットに‘１’をセット指示が生成され［Ｔ３−４］、これをセットする［Ｔ３−５］。第０カード内には、成功通知が生成される。
【０１１５】
４番目の［Ｔ４］では、まずＴ２−１やＴ３−１と同様にして、第０カードがそのリソースロックを解放し、リソースロックフラグは‘０’にリセットされリソースが解放される［Ｔ４−２］。
【０１１６】
ここで、現在優先されるカードは第１カードのみである。そこで、この第１カードから、Ｔ１−４におけるリソースロック失敗のために再発行されたリソースロック要求を受け付けると、リソースロックフラグは‘０’であるため解放されており、（ＳＴＶ（１）、ＳＴＦ（１））は（１、０）であるため第１カードは優先するカードでありリソースロック成功と判断される。
【０１１７】
ここでは、図９のステップ９１２に説明された、各フラグをリセットするかどうかの判定が実行される。つまり、ここでリソースロック成功が判定された第１カード以外はＳＴＶ（ｎ）＝ＳＴＦ（ｎ）（ｎ＝０、２、３）であるため、現時点でリソースロック競合に失敗してまだその再要求に成功していないカードは存在しないと認識され、失敗フラグ４２と成功フラグ４３の全ビットを‘０’にリセットする［Ｔ４−５］。また、第１カード内には、リソースロックフラグ成功通知が生成される［Ｔ４−４］。
【０１１８】
最後の５番目の［Ｔ５］では、第１カードがそのリソースロックを解放し、リソースロックフラグは‘０’にリセットされリソースが解放される［Ｔ５−２］。これにより、リソースロック制御部４０内のフラグは全て初期状態に戻る。
【０１１９】
以上好ましい実施の形態及び実施例をあげて本発明を説明したが、本発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形して実施することができる。
【０１２０】
【発明の効果】
以上説明したように本発明のマルチプロセッサシステムによれば、以下のような効果が達成される。
【０１２１】
従来からの排他制御用リソースロックフラグに加え、新規に回路的に小規模ながら失敗フラグと成功フラグを設ける事で、リソースロック調停部への要求受付順によらず必ず全カードのリソースロック要求を成功に導く事ができ、プロセッサタイムアウトの発生を防ぐ事ができる。
【０１２２】
またこれにより要求受付調停部の調停論理は、あるカードが優先的に選択されるようなものであっても、論理的に簡単なものや、物理量の少なくなるものを採用する事ができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態によるマルチプロセッサシステム１の構成の一例を示すブロック図である
【図２】本発明の第１の実施の形態のプロセッサが共有領域アクセス時に行うシーケンスを示したフローチャートである。
【図３】本発明の第１の実施の形態のバス要求制御部のバス要求発行制御を説明するためのフローチャートである。
【図４】本発明の第１の実施の形態の要求受付調停部による調停論理の一例を示す図である。
【図５】本発明の第１の実施の形態のリソースロック制御部の構成を説明するためのブロック図である。
【図６】本発明の第１の実施の形態のリソースロックフラグの状態値とその意味を示す図である。
【図７】本発明の第１の実施の形態の失敗フラグと成功フラグとにおける同じカードに対応するビットの値の組とその状態の説明を示す図である。
【図８】本発明の第１の実施の形態の要求受付調停部がリソースロック制御部に送る転送要求のデータ形式の一例を示す図である。
【図９】本発明の第１の実施の形態のリソースロック制御部の制御を説明するためのフローチャートである。
【図１０】本発明の第１の実施の形態のリソースロック要求とリソースアンロック要求を処理する各カードのリソースロック制御部の動作を説明するためのタイミングチャートの一例である。
【符号の説明】
１  マルチプロセッサシステム
１００  カード
１０  バス要求発行部（プロセッサ）
２０  バス要求制御部
３０  要求受付調停部
４０  リソースロック制御部
５０  要求制御部
６０  成功通知線
７０  失敗通知線
８０  バス
８１、８２、８３、８４  信号線
【図１】
0003560534.tif 000002
【図２】
0003560534.tif 000003
【図３】
0003560534.tif 000004
【図４】
0003560534.tif 000005
【図５】
0003560534.tif 000006
【図６】
0003560534.tif 000007
【図７】
0003560534.tif 000008
【図８】
0003560534.tif 000009
【図９】
0003560534.tif 000010
【図１０】
0003560534.tif 000011