"プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するリソース調停システムであって、1つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第1の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第2の識別子を少なくとも有するリクエストレジスタとを備え、第1のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第2の識別子を有する第1のリクエストがなされた場合において、前記第1のリクエストの対象となる第1のリソースが解放されたとき、当該第1のリソースのリソースレジスタの前記第1の識別子を、前記予約用グループを示すものに変更し、前記第1のリクエストの対象となるすべての前記第1のリソースについてリソースレジスタの前記第1の識別子が前記予約用グループを示すものに変更されたとき、その情報を前記第1のデバイスに通知することを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記第1のリクエストの対象となる前記第1のリソースが解放されたとき、当該第1のリソースのリソースレジスタの前記第1の識別子を、未使用の空きグループを示すものに一旦変更した後、前記予約用グループを示すものに変更することを特徴とするリソース調停システム。請求項2記載のリソース調停システムにおいて、第2のデバイスが実行予定の処理についてなされた第2のリクエストにおいて、当該第2のリクエストに係る前記第2の識別子が示す第1のグループと、前記第2のリクエストの対象となる第2のリソースのリソースレジスタの前記第1の識別子が示す第2のグループとが同じ場合、前記第2のリソースの解放後、前記第2のデバイスに前記第2のリソースを割り付ける一方、前記第1のグループと前記第2のグループとが異なる場合、前記第2のリソースが解放され、かつ、当該第2のリソースのリソースレジスタの前記第1の識別子が前記空きグループを示すものに変更された後に、前記第2のデバイスに前記第2のリソースを割り付けることを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記リソースレジスタは、前記リソースが所有されているか否かを示す第9の識別子を有しており、前記リソース調停システムは、前記第1及び第9の識別子の少なくともいずれか一方に基づいて、リソースの解放を判断することを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、同一のリソースに対する複数のリクエストの優先順位を、所定の条件に基づいて、決定することを特徴とするリソース調停システム。請求項5記載のリソース調停システムにおいて、前記リクエストは、前記リクエストレジスタに当該リクエストの優先順位を示す第4の識別子を有しており、前記リソース調停システムは、前記第4の識別子が示す優先順位に基づいて調停を行うことを特徴とするリソース調停システム。請求項5記載のリソース調停システムにおいて、前記リソースレジスタは、前記リソースが割り付けられたデバイス又は当該リソースの割り付け先の候補となる候補デバイスを示す第3の識別子を有しており、前記リクエストは、前記リクエストレジスタにリクエスト対象となるリソースを割り付けるデバイスを示す第10の識別子を有しており、前記リソース調停システムは、リクエスト対象となる第2のリソースのリソースレジスタの前記第3の識別子に示された前記候補デバイスと前記第10の識別子が示すデバイスとが同一であるリクエストを、同一でないリクエストよりも優先することを特徴とするリソース調停システム。請求項7記載のリソース調停システムにおいて、優先順位が同等である複数の前記リクエストが前記第2のリソースに対して発生した場合に、当該リクエストにおいて、前記第10の識別子が示す割り付け先デバイス同士で前記候補デバイスを決定し、当該割り付け先デバイスのうちいずれか1つが、前記第2のリソースのリソースレジスタの前記第3の識別子を、決定した前記候補デバイスを示すものに変更することを特徴とするリソース調停システム。請求項5記載のリソース調停システムにおいて、第2のデバイスが実行予定の処理についてなされた第2のリクエストにおいて、当該第2リクエストに係る前記第2の識別子が示すグループと、前記第2のリクエストの対象となる、第3のデバイスに割り付けらた第2のリソースのリソースレジスタの前記第1の識別子が示すグループとが同一か否か、及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて、前記第3のデバイスへの前記第2のリソースの解放要求の通知並びに前記第2のデバイスへの競合発生の通知、調停によるリソース確保ありの通知及び調停によるリソース確保なしの通知のうちの少なくともいずれか1つの通知を行うか否かを決定することを特徴とするリソース調停システム。請求項5記載のリソース調停システムにおいて、前記第1のリクエストの優先順位が所定の優先順位以上に設定されているとき、前記第1のリソースが割り付けられている各デバイスに、前記第1のリソースの解放要求と、前記第1のリクエストが前記予約用グループに係るリクエストであることとを通知することを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記リソースレジスタは、所定の条件に合致する前記リソースからなるリソースグループに属するか否かを示す第5の識別子を有することを特徴とするリソース調停システム。請求項11記載のリソース調停システムにおいて、複数の前記デバイスによる共有が可能な共有リソースは、前記リソースレジスタが、共有可能数と同数設けられており、前記共有リソースの各リソースレジスタの前記第5の識別子は、同一リソースグループに属することを示していることを特徴とするリソース調停システム。請求項12記載のリソース調停システムにおいて、前記共有リソースが異なる2つ以上の前記グループに属することの許可又は不許可を示す第6の識別子を少なくとも有するグローバルレジスタを備えており、前記リソースレジスタは、前記リソースが所有されているか否かを示す第9の識別子を有しており、前記リソースが解放されたとき、前記第1及び第9の識別子の少なくともいずれか一方が、リソースの解放を示すものであり、前記リソース調停システムは、前記第6の識別子が前記許可を示す前記共有リソースは、当該共有リソースへの第2のリクエストに係る前記第2の識別子が示すグループに関わらず、前記共有可能数の範囲内において前記第2のリクエスト毎にそれぞれ調停される一方、前記第6の識別子が前記不許可を示す前記共有リソースは、当該共有リソースへの前記第2のリクエストに係る前記第2の識別子が示す第1のグループと、前記共有リソースの各リソースレジスタの前記第1の識別子が示す第2のグループのうちの少なくとも1つとが異なるとき、当該第1の識別子が前記第1グループと異なるグループを示した前記リソースレジスタがすべて解放を示した後に調停されることを特徴とするリソース調停システム。請求項11記載のリソース調停システムにおいて、前記第5の識別子は、1つの処理の実行に必要な前記リソースからなるリソースグループに属するか否かを示すものであることを特徴とするリソース調停システム。請求項11記載のリソース調停システムにおいて、前記リクエストは、前記リクエストレジスタにリクエストの対象である前記リソース又は前記リソースグループを示す第7の識別子を有しており、前記リソース調停システムは、前記第7の識別子が前記リソースグループを示すリクエストを、前記第7の識別子が前記リソースを示すリクエストより優先することを特徴とするリソース調停システム。請求項15記載のリソース調停システムにおいて、前記第7の識別子が前記リソースグループを示す第2のリクエストの場合、前記リソースグループに属する第2のリソースが割り付けられている各デバイスに前記第2のリソースの解放要求を通知することを特徴とするリソース調停システム。請求項11記載のリソース調停システムにおいて、前記第5の識別子が同一の前記リソースグループに属することを示す複数の第2のリソースに、前記予約用グループを示す前記第2の識別子を有する第2のリクエストがなされた場合において、前記第2のリソースがすべて前記予約用グループに割り付けられた後に、前記第2のリソースのリソースレジスタの前記第1の識別子を一括して別のグループに更新することを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記リソースレジスタは、前記リソースが異常であることを示す第8の識別子を有しており、前記リソース調停システムは、前記第8の識別子が前記リソースの異常を示したとき、異常である前記リソースを調停の対象から外す一方、前記第8の識別子が正常であることを示したときに再び調停の対象とすることを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記リソースは、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、前記ハードウェアアクセラレータ、及び前記プロセッサと前記ハードウェアアクセラレータと前記リソースとの接続バスのうちの少なくとも1つを含んでいることを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記ハードウェアアクセラレータは、映像処理ハードウェアアクセラレータであることを特徴とするリソース調停システム。請求項1記載のリソース調停システムにおいて、前記ハードウェアアクセラレータは、音声処理ハードウェアアクセラレータであることを特徴とするリソース調停システム。プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するシステムにおけるリソース調停方法であって、前記システムは、1つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第1の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第2の識別子を少なくとも有するリクエストレジスタとを備え、前記リソース調停方法は、第1のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第2の識別子を有する第1のリクエストがなされた場合において、前記第1のリクエストの対象となる第1のリソースが解放されたとき、前記第1のリソースのリソースレジスタの前記第1の識別子を、前記予約用グループを示すものに変更するステップと、前記第1のリクエストの対象となるすべての前記第1のリソースについてリソースレジスタの前記第1の識別子が前記予約グループを示すものに変更されたとき、その情報を前記第1のデバイスに通知するステップとを備えていることを特徴とするリソース調停方法。しかしながら、規模が大きく複雑な不均質なハードウェアアクセラレータリソースからなるシステムでは、プロセッサ毎に利用するリソース数も不均質であり、共有して使用するリソースと供給しないリソースとが混在する。特許文献1の調停システムは、このようなシステムにおいてリソース割り付けを調停するのに好適ではない。また、論理的に1つの機能を実行処理するためには所定のリソースを確保する必要があり、リソースをまとめて確保したいリクエスト者にとっては、一括して確保できるか、そうでないかが重要である。特許文献1の調停システムは、このような一括した確保に対する開示はなされていない。特許文献2の調停システムは、所有者情報をリクエスト者情報に関連付けて、リソース単位でリソースを現在の所有者から確保する技術であるが、このようにリソース単位で現在の所有者からリソースを確保する場合、各リソースの所有者への解放要求等の通知が必要であり、所有者の現在の処理に影響を与えてしまうこととなる。また、リソース単位で所有者からリソースを確保するよりも、解放されたリソースが所定数を満たした段階で一括して確保した方が効果的なリソースの割り付けが可能となる。さらに、リソースのうちの1つであるメモリには、プロセッサが計算に用いるワークメモリのように局所的に共有されることなく使用されるメモリだけでなく、複数のプロセッサから同一のプログラムコードが格納されるページとして共有されるメモリがある。また、異なるアプリケーション間でのデータ受け渡し時に共有メモリがデータフローを構成する場合がある。特許文献2では、共有リソースの管理に対する開示がされていない。具体的には、所有者情報とリクエスト者情報とが異なる場合におけるリソース共有の概念が開示されていない。従って、所有者情報とリクエスト者情報とが異なるリクエストが発生した場合に、同一機能の最優先処理に対するリソースの割り付けと、異なる機能の優先処理に対するリソースの割り付けとを両立することができない。その結果、効果的なリソースの割り付けができないという課題がある。上記の点に鑑み、本発明は、複数のデバイスが使用するリソースを調停するリソース調停システムにおいて、デバイス例えば、リクエストされたリソースを所有するデバイスやリクエスト主体となるデバイスの処理への影響を抑制しつつ、効果的なリソースの割り付けを可能とするリソース調停システムを提供することを目的とする。本発明の第1態様は、プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するリソース調停システムであって、1つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第1の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第2の識別子を少なくとも有するリクエストレジスタとを備えている。前記リソース調停システムは、第1のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第2の識別子を有する第1のリクエストがなされた場合において、前記第1のリクエストの対象となる第1のリソースが解放されたとき、当該第1のリソースのリソースレジスタの前記第1の識別子を、前記予約用グループを示すものに変更し、前記第1のリクエストの対象となるすべての前記第1のリソースについてリソースレジスタの前記第1の識別子が前記予約用グループを示すものに変更されたとき、その情報を前記第1のデバイスに通知する。この第1態様によると、リソース調停システムは、第1のリクエストの対象となる第1のリソースが解放されたとき、予約用グループに第1のリソースを確保し、第1のリクエストの対象となるすべての第1のリソースについてリソースレジスタの第1の識別子が予約用グループを示すものに変更されたとき、その情報を第1のデバイスに通知する。このように、リソースが解放されてから予約用グループにリソースを確保第1の識別子を予約用グループを示すものに変更するため、現在の所有者デバイスへのリソースの解放要求を出していない。また、第1のデバイスはすべての第1のリソースが確保されてから、その情報の通知を受けるので、すべての第1のリソースが確保されたのを確認してから実行予定の処理を開始することができる。これにより、第1のリソースがすべて使用可能となったときに処理が開始でき、例えば、処理の途中にリソースが不足して処理の中断や待ちの状態になることを回避できる。一方で、デバイス及びリソースがすべて使用可能でなければ、例えば、デバイスが別の処理を行うなどの判断材料とできる。このように、本態様のリソース調停システムは、現在の所有者への影響を抑制しつつ、効果的にリソースを割り付けることができる。そして、前記第1態様のリソース調停システムは、前記第1のリクエストの対象となる前記第1のリソースが解放されたとき、当該第1のリソースのリソースレジスタの前記第1の識別子を、未使用の空きグループを示すものに一旦変更した後、前記予約用グループを示すものに変更するのが好ましい。そして、前記第1態様のリソース調停システムは、第2のデバイスが実行予定の処理についてなされた第2のリクエストにおいて、当該第2のリクエストに係る前記第2の識別子が示す第1のグループと、前記第2のリクエストの対象となる第2のリソースのリソースレジスタの前記第1の識別子が示す第2のグループとが同じ場合、前記第2のリソースの解放後、前記第2のデバイスに前記第2のリソースを割り付ける一方、前記第1のグループと前記第2のグループとが異なる場合、前記第2のリソースが解放され、かつ、当該第2のリソースのリソースレジスタの前記第1の識別子が前記空きグループを示すものに変更された後に、前記第2のデバイスに前記第2のリソースを割り付けるのが好ましい。このように、第2のリソースが属する第2のグループと第2のデバイスが属する第1のグループとが異なる場合は、空きグループを介して割り付けることにより、すべてのグループのデバイスからのリクエストに対する優先順位等を考慮した最適な効果的なリソースの割り付けを実現することができる。一方、第2のリソースが属する第2のグループと第2のデバイスが属する第1のグループとが同じ場合、第2のリソースの解放後に空きグループを介さない第2のデバイスへの第2のリソースの割り付けを実施することにより、同じグループ内でのリソースの割り付けを他グループのデバイスからのリクエストの影響を受けずに割り付け及び処理の開始をすることが可能となるとともに、処理中の他グループのデバイスにその影響が及ばない。そして、前記第1態様のリソース調停システムは、同一のリソースに対する複数のリクエストの優先順位を、所定の条件に基づいて、決定するのが好ましい。これにより、例えば先ほどの予約用グループへの第1のリソースの割り付けを優先順位を高く設定して行うことができる。これにより、予約用グループに第1のリソースが一括して確保割り付けされるまでの時間が短縮される。また、例えばリソースのうち確保するまで処理が実行できないリソースがある場合等にそのリソースの優先順位を高く設定することができる。このように、一括確保されるまでの時間短縮や処理の実行に不可欠なリソースの優先確保等が実現され、さらに効果的なリソースの割り付けが可能となる。そして、前記第1態様のリソース調停システムのリソースレジスタは、所定の条件に合致する前記リソースからなるリソースグループに属するか否かを示す第5の識別子を有するのが好ましい。そして、複数の前記デバイスによる共有が可能な共有リソースは、前記リソースレジスタが、共有可能数と同数設けられており、前記共有リソースの各リソースレジスタの前記第5の識別子は、同一リソースグループに属することを示しているのが好ましい。そして、前記第1態様のリソース調停システムは、前記共有リソースが異なる2つ以上の前記グループに属することの許可又は不許可を示す第6の識別子を少なくとも有するグローバルレジスタを備えており、前記リソースレジスタは、前記リソースが所有されているか否かを示す第9の識別子を有しており、前記リソースが解放されたとき、前記第1及び第9の識別子の少なくともいずれか一方が、リソースの解放を示すものであるのが好ましい。そして、前記第1態様のリソース調停システムは、前記第6の識別子が前記許可を示す前記共有リソースは、当該共有リソースへの第2のリクエストに係る前記第2の識別子が示すグループに関わらず、前記共有可能数の範囲内において前記第2のリクエスト毎にそれぞれ調停される一方、前記第6の識別子が前記不許可を示す前記共有リソースは、当該共有リソースへの前記第2のリクエストに係る前記第2の識別子が示す第1のグループと、前記共有リソースの各リソースレジスタの前記第1の識別子が示す第2のグループのうちの少なくとも1つとが異なるとき、当該第1の識別子が前記第1グループと異なるグループを示した前記リソースレジスタがすべて解放を示した後に調停されるのが好ましい。このように、グループを越えた共有を許可するか否かを判別して、リソースの割り付けを管理することにより、リソースをグループを越えて活用共有することができる。これにより、さらに効果的なリソースの割り付けが可能となる。そして、前記第1態様のリソース調停システムは、第2のデバイスが実行予定の処理についてなされた第2のリクエストにおいて、当該第2リクエストに係る前記第2の識別子が示すグループと、前記第2のリクエストの対象となる、第3のデバイスに割り付けられた第2のリソースのリソースレジスタの前記第1の識別子が示すグループとが同一か否か、及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて、前記第3のデバイスへの前記第2のリソースの解放要求の通知並びに前記第2のデバイスへの競合発生の通知、調停によるリソース確保ありの通知及び調停によるリソース確保なしの通知のうちの少なくともいずれか1つの通知を行うか否かを決定するのが好ましい。このように、第2リクエストに係る第2の識別子が示すグループと、第2のリクエストの対象となる第2のリソースが属するグループとが同一か否か及び前記所定の条件に基づく優先順位の少なくともいずれか一方に基づいて通知を実施することにより、第2のリソースの所有者である第3のデバイスの処理への影響を抑制することができる。例えば、優先順位が所定の優先順位よりも低いリクエストに関する各通知を行わないこととすれば、各通知による第2のデバイス及び第3のデバイスの処理への影響を与えずにすむ。本発明の第2態様は、プロセッサ及びハードウェアアクセラレータのうちいずれか一方である複数のデバイスが使用するリソースを調停するシステムにおけるリソース調停方法であって、前記システムは、1つの処理を実行する前記デバイス及び当該実行に必要な前記リソースの集まりを、グループとして管理するものであり、前記リソース毎に設けられ、当該リソースが属するグループを示す第1の識別子を少なくとも有するリソースレジスタと、前記リソースの使用を要求するリクエストを格納するものであり、前記リクエストは、リクエスト対象となるリソースを割り付けるグループを示す第2の識別子を少なくとも有するリクエストレジスタとを備え、前記リソース調停方法は、第1のデバイスが実行予定の処理について、当該処理に必要な前記リソースを割り付ける予約用グループを示す前記第2の識別子を有する第1のリクエストがなされた場合において、前記第1のリクエストの対象となる第1のリソースが解放されたとき、前記第1のリソースのリソースレジスタの前記第1の識別子を、前記予約用グループを示すものに変更するステップと、前記第1のリクエストの対象となるすべての前記第1のリソースについてリソースレジスタの前記第1の識別子が前記予約グループを示すものに変更されたとき、その情報を前記第1のデバイスに通知するステップとを備えている。本発明によれば、実行予定の処理のグループに割り付けられたデバイス及びリソースを、デバイスの処理機能の実行への影響を抑制しつつ、一括して確保することができる。これにより、例えばリクエストされたリソースを所有するデバイスやリクエスト主体となるデバイスリクエストにおいてリソースの割り付け先となるデバイスのようなデバイスの処理への影響を抑制しつつ、効果的にリソースを割り付けることが可能なリソース調停システムを提供することができる。以下、本発明の実施形態について図面を参照しながら説明する。図1は本発明の一実施形態に係る調停システムの構成例を示す図である。図1において、プロセッサ1とハードウェアアクセラレータ2とリソース3とは、選択ユニット4に接続されている。プロセッサ1は、ハードウェアアクセラレータ2及びリソース3を使って、映像処理、音声処理及びグラフィック処理等を実行するデバイスである。ハードウェアアクセラレータ2は、映像処理、音声処理及びグラフィック処理等の主要部分あるいはすべてをアクセラレートするためにハードウェア化されており、プロセッサ1から制御される。リソース3は、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、及びプロセッサ1とハードウェアアクセラレータ2とリソース3との接続バス等からなる。また、本実施形態においては、プロセッサ1から見たハードウェアアクセラレータ2もリソースに含むものとする。すなわち、ハードウェアアクセラレータ2は、メモリ、入出力デバイス、通信デバイス、グラフィック用デバイス、及び接続バス等のリソース3を使用して映像処理及び音声処理等の処理を行うデバイスである一方、プロセッサ1から制御されるリソースでもある。本実施形態において、デバイスとは、プロセッサ1及びハードウェアアクセラレータ2を指すものとする。実行する処理に応じて、必要なプロセッサ1の数、ハードウェアアクセラレータ2の数及びタイプ並びにリソース3の数等は異なる。なお、リソース3の1つであるメモリは、複数のデバイスプロセッサ1及びハードウェアアクセラレータ2からのアクセスが同時に可能な共有リソース共有メモリであってもよい。例えば、2つのハードウェアアクセラレータ2からのリードとライトとが同時に可能なメモリであってもよい。これにより、例えば、ハードウェアアクセラレータ2がメモリにライトしたデータを、他のハードウェアアクセラレータ2がリードすることができる。また、リソース3の1つであるメモリは、物理メモリに限定されず、アドレス管理された論理アドレスの一部分であってもよいし、ページング方式やセグメント方式に基づいて管理されるメモリの一部分であってもよい。また、共有リソースはメモリに限定されない。例えば、共有リソースは時分割で利用される入出力デバイスや、ハードウェアアクセラレータ2であってもよい。例えば、共有リソースとして使用されるハードウェアアクセラレータ2は、複数のプロセッサ1から利用され、データ処理、映像処理及び音声処理などの複数の処理を並列に実行し、異なる処理結果を生成するものであってもよい。選択ユニット4は、内部に有するレジスタ5の情報後述の各識別子に基づいて、リソース3を所有するデバイス1,2への解放要求を通知する。また、リソース3の使用要求であるリクエストを受け、調停によりリソース3を割り付けるデバイス1,2を決定し、決定したデバイス1,2からリソース3へのアクセスが可能となるように接続関係を変更する。なお、以下ではリソース3を割り付けたデバイス1,2をそのリソース3の所有者1,2と記載し、デバイス1,2からリソース3へアクセスができる状態を、デバイスがリソース3を所有している、又は確保していると記載する。具体的には、例えば、プロセッサ1とリソース3ハードウェアアクセラレータ2を含むとの間の制御バスや、ハードウェアアクセラレータ2とリソース3ハードウェアアクセラレータ2は含まないとの間のデータバス等の物理的な接続が変更される。なお、接続関係の変更は物理的な接続の変更に限定されない。例えば、プロセッサ1から特定のリソース3ハードウェアアクセラレータ2を含むに関するアクセス権や、ハードウェアアクセラレータ2から特定のリソース3ハードウェアアクセラレータ2を含まないへのアクセス権が変更されることによっても、接続関係の変更がなされる。また、本実施形態では、後述する1つの機能の処理を実行するために割り付けられたデバイス1,2及びリソース3の集まりであるグループがあり、選択ユニット4はこのグループによるリソース3の割り付けの管理を行う。また、実行予定の処理に必要なリソース3を割り付ける予約用グループに対してのリソース3の割り付けも行う。そして、選択ユニット4とリクエストを行ったデバイス1,2以下リクエスト者1,2と記載する。との間では、リソース3のリクエスト、調停及び解放に係る情報を交換する。例えば、リクエスト及びリクエスト者1,2を示す情報、リクエストに対する調停結果、競合を示す情報及び所有するリソース3の解放要求を示す情報等を交換する。デバイス1,2は、この選択ユニット4と交換する情報をリソース3の解放の判断材料とする。<レジスタ>図2は、本実施形態に係るレジスタ5の構成例を示す図である。レジスタ5は、プロセッサ1及びハードウェアアクセラレータ2並びに選択ユニット4からリード及びライト設定及び更新ができる。本実施形態では、レジスタ5はリソースレジスタ10、リクエストレジスタ11及びグローバルレジスタ12を備えている。リソースレジスタ10はリソース3毎に設けられる。例えば、リソース3がn個nは自然数の場合、リソースレジスタ10はn個用意される。そして、リソースレジスタ10は、リソース3が属するグループを示す第1の識別子であるリソースグループビットgid_rs、リソース3が割り付けられたデバイス1,2又はリソース3の割り付け先の候補となるデバイス1,2である候補デバイスを示す第3の識別子であるリクエスト者識別ビットrqid_rs、リソース3が所有されているか否かを示す第9の識別子である所有ビットownership:以下ownerと表記する、所定の条件に合致するリソース3からなるリソースグループrg0~rg3に属するか否かを示す第5の識別子である特定リソースビットrg0~rg3、及びリソース3が異常であることを示す第8の識別子であるエラービットerrorを有している。本実施形態では、特定リソースビットrg0~rg3は、後述する共有リソースの共有可能数用意された各リソースレジスタが同一の共有リソースに属するか否かを示すものrg0,rg1、及び各処理の実行に必要なリソースの集まりを示すものrg2,rg3を含んでいる。なお、特定リソースビットrg0~rg3が示す各リソースグループを構成するリソース3の条件は、ここで述べたものに限らない。なお、共有リソース3については、複数となる所有者1,2を識別するために、共有可能な所有者1,2と同数のリソースレジスタ10が用意される。リクエストレジスタ11は、リソース3の使用を要求するリクエストを格納するものである。本実施形態では、リクエスト毎にリクエストレジスタは設けられる。したがって、デバイス1,2からm個mは自然数のリクエストが発生した場合、リクエストレジスタ11がm個用意される。なお、リソースレジスタ及びリクエストレジスタを各1個用意し、それぞれ領域を分割してリソース及びリクエストを管理してもよいし、リソース間及びリクエスト間で所定のビットを共有して使用してもよい。そして、リクエストレジスタ11は、リクエスト対象となるリソースを割り付けるグループを示す第2の識別子であるリクエストグループビットgid_rq、リクエスト対象となるリソースを割り付けるデバイスを示す第10の識別子であるビットrqid_rq、リクエストの優先順位を示す第4の識別子である優先順位ビットpriority、及びリクエストの対象であるリソース3又はリソースグループrg0~rg3を示す第7の識別子であるリクエスト対象ビットridを有している。グローバルレジスタ12は、リソースグループrg0~rg3のリソース3について、異なるグループのデバイス1,2による共有の許可又は不許可を示す第6の識別子である共有ビットrg0_type~rg3_typeを有している。また、図2には各レジスタ10,11,12の初期値initialの一例を記載している。<構成要素>図3は本実施形態に係る調停システムの構成要素例を示す図である。図3aに示すように、リソースのリクエスト者は、デバイスであるプロセッサPE0~PE3図1におけるプロセッサ1及びハードウェアアクセラレータHA0~HA2図1におけるハードウェアアクセラレータ2からなり、リソースレジスタ10におけるリクエスト者識別ビットrqid_rs及びリクエストレジスタ11におけるビットrqid_rqに設定される識別子rqidによって識別される。本実施形態では、識別子rqidとして、プロセッサPE0~PE3にはそれぞれ0~3が付与されており、ハードウェアアクセラレータHA0~HA2にはそれぞれ4~6が付与されている。また、リクエスト者が未設定であることを示す識別子rqidとして15が付与されている。なお、識別子rqidはあらかじめ付与されていてもよいし、例えば実行開始前等に付与されてもよい。図3bに示すように、リソース3は、R0~R3,R4-0,R4-1,R5-0,R5-1,R6以下、R0~R6と記載する及びハードウェアアクセラレータHA0~HA2からなる。ここで、リソースR4-0,R4-1及びリソースR5-0,R5-1は、それぞれ2つのデバイスによる共有が可能な共有リソースR4,R5を表している。このように、リソース3が共有リソースの場合、共有可能数分のリソースレジスタ10を用意するとともに、共有可能数分の異なる識別子本実施形態ではrid=4,5および6,7の各2つの識別子を用意し、別々のリソースR4-0,R4-1およびR5-0,R5-1として扱うものとする。なお、本実施形態では2つのデバイスによる共有が可能な共有リソースR4,R5の例を示しているが、例えば共有リソースR4が3つのデバイスによる共有が可能な場合には、リソースR4-0,R4-1,R4-2の3つのリソースとして扱う。リソースR0~R3,R6は共有リソース3ではない。また、図3では示されていないが、ハードウェアアクセラレータHA0はリソースR0、ハードウェアアクセラレータHA1はリソースR1、及びハードウェアアクセラレータHA2はリソースR2をそれぞれの処理に用いるものとする。図3bの右側の4列は各リソースR0~R6,HA0~HA2と関連付けされたリソースグループrg0~rg3の一例を示している。本実施形態において、特定リソースビットrg0~rg3は図3bのようにあらかじめ設定されているものとする。なお、特定リソースビットrg0~rg3の設定はこれに限定されず、例えば実行開始前等にプロセッサPE0~PE3が設定又は変更できるようにしてもかまわない。図3bにおいて、各リソースR0~R6,HA0~HA2には、リクエストレジスタ11におけるリクエスト対象ビットridに設定するための識別子ridが付与されている。例えば、リソースR0には識別子ridとして0が付与されており、デバイスPE0~PE3,HA0~HA2からリソースR0をリクエストする際には、リクエスト対象ビットridに0が設定される。同様に、他のリソースR1~R6,HA0~HA2にもそれぞれ1~11の識別子ridが付与されている。また、リクエストするリソースが未設定であることを示す識別子ridとして31が付与されている。なお、識別子ridはあらかじめ付与されていてもよいし、例えば実行開始前等に付与されてもよい。特定リソースビットrg0は、共有リソースR4を示しており、リソースR4-0,R4-1に1が設定され、それ以外のリソースR0~R3,R5-0,R5-1,R6,HA0~HA2には0が設定されている。また、特定リソースビットrg0に係る共有ビットrg_type、図2のグローバルレジスタ12におけるrg0_typeは0が設定されており、共有リソースR4はグループを越えた共有が不許可であることを示している。同様に、特定リソースビットrg1は、共有リソースR5を示しており、リソースR5-0,R5-1に1が設定され、それ以外のリソースR0~R3,R4-0,R4-1,R6,HA0~HA2には0が設定されている。また、特定リソースビットrg1に係るグループ共有ビットrg_type、図2のグローバルレジスタ12におけるrg1_typeは1が設定されており、共有リソースR5はグループを越えた共有が許可されることを示している。特定リソースビットrg2は、映像処理に係る機能の実行に必要なリソースからなるリソースグループrg2を示しており、リソースR1,R4-0,R4-1,R5-0,HA1に1が設定されている。また、特定リソースビットrg2に係る共有ビットrg_type、図2のグローバルレジスタ12におけるrg2_typeには0が設定されている。特定リソースビットrg3は、グラフィック処理に係る機能の実行に必要なリソースからなるリソースグループrg3を示しており、リソースR1,R6,HA1に1が設定されている。また、特定リソースビットrg3に係る共有ビットrg_type、図2のグローバルレジスタ12におけるrg3_typeには0が設定されている。具体的には、リソースR4-0,R4-1は、特定リソースビットrg0及び共有ビットrg_typeの値からグループを越えた共有を許可されていない共有リソースR4であり、両方が特定リソースビットrg2に係る映像処理用のリソース3として設定されているため、この映像処理が行われているときには、リソースR4-0,R4-1は映像処理用として原則使用される。これに対して、リソースR5-0,R5-1は特定リソースビットrg1及び共有ビットrg_typeの値からグループを越えた共有を許可された共有リソースR5であるため、例えばリソースR5-0が特定リソースビットrg2の映像処理に使用されていたとしても、リソースR5-1は他のグループによる使用が可能である。なお、リクエスト対象ビットridには、図4bに示す識別子ridに加えて、特定リソースビットrg0~rg3によって示されたリソースグループrg0~rg3を示す識別子図示せずを設定することも可能である。例えば、図4bで使用していない識別子12~30を使用してもよい。図4は本実施形態に係る調停システムによるリソース割り付け状況を示す図である。図4は各ケース0~3において、リソースグループビットgid_rs及びリクエストグループビットgid_rqに設定される識別子gid、並びに識別子gidが設定された第0~第4グループG0~G4のリソース割り付け状況を示している。例えば、第0グループG0には、識別子gidとして0が付与されている。同様に、第1~第4グループG1~G4にはそれぞれ識別子gidとして1~4が付与されている。このように、1つの機能を実行するために割り付けられたデバイス及びリソースの集まりを、グループとして管理する。また、識別子gidとして15が付与された未使用のグループを空きグループG15として使用する。そして、デバイスPE0~PE3,HA0~HA2に確保されていないリソースR0~R6,HA0~HA2は空きグループG15に割り付けるものとする。<A.ケース0からケース1への移行に係る動作>図4において、ケース0はいずれの処理にもリソースR0~R6,HA0~HA2が確保されていない状況を示しており、リソースR0~R6,HA0~HA2は空きグループG15に割り付けされている。図5は、ケース0における各リソースのリソースレジスタ10の各ビットの値を示している。識別子ridとして0が付与されているリソースR0には、リソースグループビットgid_rsとして空きグループを示す15が設定されており、リクエスト者識別ビットrqid_rsとして未設定であることを示す15が設定されている。リソースR0はいずれのデバイスPE0~PE3,HA0~HA2からも所有確保されておらず、エラーは発生していないため、所有ビットowner及びエラービットerrorには、それぞれ0が設定されている。特定リソースビットrg0~rg4は図3と同じ値となっている。リソースR1~R6,HA~HA2のリソースレジスタ10にも同様に値が設定されている。図4に示すように、ケース1では第0~第2グループG0~G2において、それぞれ映像処理、音声処理及びシステム処理が実施される。これに伴い、第0グループG0では、映像処理用として、プロセッサPE0はリソースR4-0,R4-1,R5-0を確保する。同様に、プロセッサPE1はハードウェアアクセラレータHA1を確保し、ハードウェアアクセラレータHA1はリソースR1を確保する。第1グループG1では、音声処理用として、プロセッサPE2はハードウェアアクセラレータHA2とリソースR5-1を確保し、ハードウェアアクセラレータHA2はリソースR2を確保する。第2グループG2では、システム処理用として、プロセッサPE3はリソースR3を確保し、ハードウェアアクセラレータHA0はリソースR0を確保する。なお、第2グループG2におけるシステム処理では、プロセッサPE3とハードウェアアクセラレータHA0とは独立して処理を実施するものとし、プロセッサPE3によってハードウェアアクセラレータHA0は確保されないものとする。ここで、選択ユニット4による調停は、所定期間内に発生したリクエストに対してまとめて行われるものとする。本実施形態では、所定の期間として、例えばケース0の開始からケース0からケース1への移行までの期間のように各ケース間の開始からそのケースから次のケースへの移行までの期間とする。なお、所定の期間は上記の期間に限定されず、変更されてもかまわない。以下に、各デバイスPE0~PE3,HA0~HA2がリソースR0~R6,HA0~HA2を確保する状況について説明する。A-1.プロセッサPE1によるハードウェアアクセラレータHA1の確保ケース0において、ハードウェアアクセラレータHA1のリソースレジスタ10の各ビットには、gid_rs=未設定、rqid_rs=未設定、owner=0が設定されている。ここで、リソースグループビットgid_rsは識別子gidとして15が設定されている。以下において説明の便宜上、リソースグループビットgid_rsに15が設定される場合は、未設定と記述する。同様にリクエスト者識別ビットrqid_rsは識別子rqidとして空きグループG15を示す15が設定されているが、説明の便宜上未設定と記述する。また、リソースレジスタ10のうち、エラービットerrorについて記述がされていない記述を省略している場合は、識別子として0が設定されているものとする。また、特定リソースビットrg0~rg4について記述がされていない記述を省略している場合は、図3と同じ値になっているものとする。プロセッサPE1は、ハードウェアアクセラレータHA1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=PE1、priority=0、rid=HA1を設定する。ここで、ビットrqid_rqには、プロセッサPE1を示す識別子rqidとして1が設定されるが、説明の便宜上PE1と記載する。同様に、リクエスト対象ビットridには、ハードウェアアクセラレータHA1を示す識別子ridとして10が設定されるが、説明の便宜上HA1と記載する。プロセッサPE1は、上記のようにリクエストグループビットgid_rqを0に設定して、リソースを割り付けるグループG0を示すことにより、ハードウェアアクセラレータHA1を第0グループG0の映像処理で使用することを示している。なお、以下においてリクエスト者識別ビットrqid_rs、リソースグループビットgid_rs、ビットrqid_rq及びリクエスト対象ビットridの設定は、設定値数字ではなく、デバイス名PE0~PE3,HA0~HA2及びリソース名R0~R6,HA0~HA2を用いて記載する。ケース0において、ハードウェアアクセラレータHA1はデバイスPE0~PE3のいずれにも所有されていないため、リクエストにおいてリソースの割り付け先となるデバイスリクエスト主体となるデバイスPE1が属するグループG0に関係なく所定期間内に発生したリクエストに対して調停が行われる。ケース0からケース1にかけて、ハードウェアアクセラレータHA1に対するリクエストはプロセッサPE1からのみであるため、競合は発生しない。したがって、選択ユニット4は、調停の結果としてハードウェアアクセラレータHA1の所有者をプロセッサPE1に決定し、ハードウェアアクセラレータHA1のリソースレジスタ10の設定を、gid_rs=0←未設定、rqid_rs=PE1←未設定、owner=1←0と更新する。その後、選択ユニット4はプロセッサPE1にハードウェアアクセラレータHA1が確保されたことを通知する。このようにして、プロセッサPE1によってハードウェアアクセラレータHA1は確保される。ここで、選択ユニット4は、プロセッサPE1からのハードウェアアクセラレータHA1のリクエストに係るリクエストレジスタ11をリセットする。具体的には、リクエストレジスタ11の各ビットに、gid_rq=未設定←0、rqid_rq=未設定←PE1、priority=0、rid=未設定←HA1を設定する。上記と同様のフローによりプロセッサPE2,PE3はそれぞれハードウェアアクセラレータHA2,HA0を確保する。このとき、選択ユニット4はハードウェアアクセラレータHA2のリソースレジスタ10の設定を、gid_rs=1←未設定、rqid_rs=PE2←未設定、owner=1←0と更新する。また、選択ユニット4はハードウェアアクセラレータHA0のリソースレジスタ10の設定を、gid_rs=2←未設定、rqid_rs=PE3←未設定、owner=1←0と更新する。同様に、ハードウェアアクセラレータHA0~HA2はそれぞれリソースR0~R2を確保する。このとき、選択ユニット4はリソースR0~R2のリソースレジスタ10の設定をそれぞれ、リソースR0は、gid_rs=2←未設定、rqid_rs=HA0←未設定、owner=1←0リソースR1は、gid_rs=0←未設定、rqid_rs=HA1←未設定、owner=1←0リソースR2は、gid_rs=1←未設定、rqid_rs=HA2←未設定、owner=1←0と更新する。同様にプロセッサPE0はリソースR5-0を確保する。このとき、選択ユニット4はリソースR5-0のリソースレジスタ10の設定を、gid_rs=0←未設定、rqid_rs=PE0←未設定、owner=1←0と更新する。A-2.プロセッサPE0によるリソースR4-0,R4-1の確保ケース0において、リソースR4-0,R4-1のリソースレジスタ10の各ビットには、gid_rs=未設定、rqid_rs=未設定、owner=0が設定されている。プロセッサPE0は、リソースR4-0,R4-1に対するリクエストとしてリクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=PE0、priority=0、rid=rg0を設定する。このとき、リクエスト対象ビットridには共有リソースR4を示すリソースグループrg0を指す識別子rg0が設定されている。このように、リソースグループrg0~rg3をリクエストの対象とするときは、そのリソースグループを示す識別子rg0~rg3をリクエスト対象ビットridに設定する。ケース0において、リソースR4-0,R4-1はともにデバイスPE0~PE3,HA0~HA2いずれにも所有されていないため、リクエスト主体となるデバイスPE0が属するグループG0に関係なく所定期間内に発生したリクエストに対して調停される。ここで、ケース0からケース1にかけてのリソースR4-0,R4-1に対するリクエストはプロセッサPE0からのみであるため、競合は発生しない。また、リソースR4-0,R4-1の共有ビットrg_typeは0であるが、両方のリソースR4-0,R4-1ともに第0グループG0を示すリクエストを受けているので割り付けが可能である。したがって、選択ユニット4は調停の結果として、リソースR4-0,R4-1の所有者をプロセッサPE0に決定し、リソースR4-0,R4-1のそれぞれのリソースレジスタ10の設定を、gid_rs=0←未設定、rqid_rs=PE0←未設定、owner=1←0と更新する。その後、選択ユニット4は、プロセッサPE0にリソースR4-0,R4-1が確保されたことを通知する。このようにして、プロセッサPE0によってリソースR4-0,R4-1は確保される。A-3-1.プロセッサPE2によるリソースR5-1の確保ここでは、リソースR5-0はプロセッサPE0によって既に確保されているものとして説明する。ケース0において、リソースR5-1のリソースレジスタ10の各ビットには、gid_rs=未設定、rqid_rs=未設定、owner=0が設定されている。プロセッサPE2は、リソースR5-1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=1、rqid_rq=PE2、priority=0、rid=R5-1を設定する。リソースR5-0,R5-1の共有ビットrg_typeは1であり、各グループを越えた共有が許可される。すなわち、リソースR5-0,R5-1は、それぞれのリソースグループビットgid_rsが異なってもよい。したがって、リクエスト者PE2が設定するリクエストグループビットgid_rqが示すグループG1に関わらず、リソースR5-0,R5-1の各リソースレジスタ10のうちいずれかの一方が解放を示していれば、それぞれR5-0,R5-1をリクエスト対象としたリクエストに対して、それぞれに調停される。ここで、ケース0からケース1にかけてのリソースR5-1に対するリクエストはプロセッサPE2からのみであるため、競合は発生しない。したがって、選択ユニット4は、調停の結果としてリソースR5-1の所有者をプロセッサPE2に決定し、リソースR5-1のリソースレジスタ10の設定を、gid_rs=1←未設定、rqid_rs=PE2←未設定、owner=1←0と更新する。その後、選択ユニット4は、プロセッサPE2にリソースR5-1が確保されたことを通知する。このようにして、プロセッサPE2によってリソースR5-1は確保される。A-3-2.プロセッサPE2によるリソースR5-1の確保の他の例ここで、上記のA-3-1の他の例として、共有リソースR5の共有ビットrg_typeが0のときのプロセッサPE2によるリソースR5-1のリクエストの例について説明する。本説明は、上記のA-3-1と対比させるためのものであり、図3bに示した共有ビットrg_typeとは異なる設定の例である。なお、ここでもリソースR5-0はプロセッサPE0によって既に確保されているものとして説明する。上記のA-3-1と同様に、ケース0において、リソースR5-1のリソースレジスタ10の各ビットには、gid_rs=未設定、rqid_rs=未設定、owner=0が設定されている。また、プロセッサPE2は、リソースR5-1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=1、rqid_rq=PE2、priority=0、rid=R5-1を設定する。先ほどの仮定により、リソースR5-0,R5-1の共有ビットrg_typeは0であり、各グループを越えた共有が許可されない。リクエスト者リクエスト主体となるデバイスPE2が第1グループG1の音声処理においてリソースR5-1を確保するためには、第0グループG0の映像処理においてリソースR5-0を使用するプロセッサPE0からリソースR5-0が解放される必要があり、選択ユニット4はプロセッサPE0からリソースR5-0が解放されてから、すなわちリソースR5-0のリソースグループビットgid_rsが未設定となってから調停を行う。このように、グループG0~G3を越えた共有を許可されないリソースR5-0,R5-1に関して、共有リソースR5-0のリソースグループビットgid_rsの示すグループG0と共有リソースR5-1のリクエスト主体となるデバイスPE2の属するグループG1とが異なる場合は、特定リソースビットrg1に示された共有リソースR5R5-0,R5-1がすべて解放されてから調停が行われる。なお、以降の説明では共有リソースR5R5-0,R5-1の共有ビットrg_typeは1として説明を行う。すなわち、リソースR5-1はケース0からケース1への移行に伴いプロセッサPE2に確保されており、リソースR5-1のリソースレジスタ10の設定は、gid_rs=1、rqid_rs=PE2、owner=1、rg0=0、rg1=1、rg2=0、rg3=0となっているものとして以降の説明を行う。A-4.プロセッサPE3によるリソースR3の確保ここでは、リソースR3はプロセッサPE2からもリクエストされている、すなわち競合が発生しているものとして説明する。ケース0において、リソースR3のリソースレジスタ10の各ビットには、gid_rs=未設定、rqid_rs=未設定、owner=0が設定されている。プロセッサPE2は、リソースR3に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=1、rqid_rq=PE2、priority=0、rid=R3を設定する。プロセッサPE3は、リソースR3に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=2、rqid_rq=PE3、priority=1、rid=R3を設定する。ここで、プロセッサPE3は優先順位ビットpriorityに1を設定している。このとき、リクエスト者PE2,PE3のリソースR3に対するリクエストにおいて、競合が発生している。優先順位ビットpriorityは調停の優先順位を示すため、リクエスト者PE3のリクエストが優先される。この結果、選択ユニット4は調停の結果としてリソースR3の所有者をプロセッサPE3に決定し、リソースR3のリソースレジスタ10の設定を、gid_rs=2←未設定、rqid_rs=PE3←未設定、owner=1←0と更新する。その後、選択ユニット4はプロセッサPE3にリソースR3が確保されたことを通知する。一方で、選択ユニット4はプロセッサPE2にリソースR3が確保されなかったことは通知しない。ここで、選択ユニット4は、プロセッサPE3からのリソースR3のリクエストに係るリクエストレジスタ11をリセットする。具体的には、リクエストレジスタ11の各ビットに、gid_rq=未設定、rqid_rq=未設定、priority=0、rid=未設定を設定する。なお、プロセッサPE2からのリソースR3のリクエストに係るリクエストレジスタ11はリセットしない。このように、複数のリクエスト者PE2,PE3からのリクエストが発生した場合には、所定の優先順位に従って調停される。ここでは、そのリソースを確保するまで処理を実行できないリクエスト者について、優先順位を高く設定するものとしている。すなわち、デバイスPE3がリソースR3を確保するまでシステム処理を実行することができないものとし、デバイスPE3について、優先順位ビットpriorityに1を設定し、優先順位を高くしている。なお、優先順位の設定はここで示した条件に限られるものではなく、他の条件に基づいて優先順位付けしてもよい。ここで、選択ユニット4は、優先順位ビットpriorityに0が設定されているプロセッサPE2には調停の結果としてリソース確保がなされなかったことを通知していない。このように、本実施形態では、リソースが確保された場合の通知は、いかなるリクエスト主体にも実施する一方、リソースが確保されなかった場合の通知は、リクエスト主体が属するグループがリソースが属するグループと同じか異なるかによらず、優先順位ビットpriorityが1のときのみ実施するものとする。このように、優先順位ビットpriorityに0が設定されているリクエスト主体となるデバイスPE2には、リソースが確保されなかったことを通知しないことにより、リクエスト主体となるデバイスPE2の処理に影響を与えずにすむ。図6はケース0からケース1への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース0においては、すべてのリソースR0~R6,HA0~HA2が空きグループG15に属しており、ケース0からケース1への移行に伴いリソースR0~R5R5-0,R5-1,HA0~HA2はいずれかのデバイスPE0~PE3,HA0~HA2に確保され、リソースR6のみがケース1においていずれのデバイスPE0~PE3,HA0~HA2にも確保されず、空きグループG15に属している。<B.ケース1からケース2への移行に係る動作>次に、図4においてケース1からケース2への移行に係る動作について説明する。図4に示すように、ケース2ではリソースR3の所有者がプロセッサPE3からプロセッサPE2に変更されており、リソースR4-1の所有者がプロセッサPE0からハードウェアアクセラレータHA1に変更されている。また、後述するグラフィック処理機能処理に使用するリソースR1,R6,HA1を割り付ける予約用グループが第3グループG3に作成されている。B-1.リソースR3の所有者の変更図6に示すように、ケース1において、リソースR3のリソースレジスタ10の各ビットには、gid_rs=2、rqid_rs=PE3、owner=1が設定されている。プロセッサPE2はリソースR3に対するリクエストとしてリクエストレジスタ11の各ビットに、gid_rq=1、rqid_rq=PE2、priority=1、rid=R3を設定する。ここで、優先順位ビットpriorityは先ほどの0から1に変更され、優先順位が高くなったものとする。選択ユニット4はリクエスト主体となるデバイスPE2にリソースR3に係る調停結果として、競合が発生していることを通知する。本実施形態では、リクエスト主体が属するグループが、リソースが属するグループと同じか異なるかによらず、優先順位ビットpriorityが1のときのみリクエスト主体に競合発生を通知するものとする。なお、競合発生の通知はこれに限定されない。例えば、リクエスト主体が属するグループが、リソースが属するグループと異なる場合に、競合発生を通知するものとしてもよい。一方で、選択ユニット4はプロセッサPE3に、所有するリソースR3の解放要求を示す情報を通知する。本実施形態では、リクエストの割り付け先となるデバイスが属するグループG1が、リソースが属するグループと異なっており、かつ、リクエストレジスタ11の優先順位ビットpriorityが1のときのみ、所有者に解放要求を通知するものとする。なお、解放要求の通知はこの条件に限定されない。例えば、リソースのリソースグループビットgid_rsと、リクエスト者が設定したリクエストグループビットgid_rqとが示す識別子gidが異なる場合、優先順位ビットpriorityの値に関わらず所有者に解放要求を通知するものとしてもよい。プロセッサPE3は選択ユニット4からの解放要求の通知をリソースR3の解放の判断材料とし、リソースR3を解放が可能となった時点で解放する。この解放のとき、プロセッサPE3はリソースR3のリソースレジスタ10の各ビットを、gid_rs=未設定←2、rqid_rs=未設定←PE3、owner=0←1と更新する。これにより、解放されたリソースR3は空きグループG15に属し、リクエスト主体となるデバイスPE2が属するグループG1リクエスト先のグループG1に関係なく、所定期間内に受けたリクエスト者PE2からのリクエストに対して調停されることとなる。選択ユニット4は、調停の結果としてリソースR3の所有者をプロセッサPE2に決定し、リソースR3のリソースレジスタ10の設定を、gid_rs=1←未設定、rqid_rs=PE2←未設定、owner=1←0と更新する。その後、選択ユニット4はプロセッサPE2にリソースR3が確保されたことを通知する。このようにして、プロセッサPE2によってリソースR3は確保される。このように、グループG0~G4の移動を伴う所有者PE0~PE3,HA0~HA2の変更が発生する場合、リソースは空きグループG15を介して調停される。B-2-1.リソースR4-1の所有者の変更ここでは、ハードウェアアクセラレータHA1はリソースR4-1が確保されなければ処理が継続できなくなるものとする。このような状況は、例えばリソースR4-1にプロセッサPE0の処理結果が格納されており、ハードウェアアクセラレータHA1がそれを利用して処理する場合などに発生する。また、リソースR4-1はプロセッサPE1からもリクエストされているものとする。図6に示すように、ケース1において、リソースR4-1,R4-0のリソースレジスタ10の各ビットには、gid_rs=0、rqid_rs=PE0、owner=1が設定されている。プロセッサPE1は、リソースR4-1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=PE1、priority=0、rid=R4-1を設定する。プロセッサPE0は、リソースR4-1のリクエストに係るリクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=HA1、priority=1、rid=R4-1を設定する。ここで、プロセッサPE0は、ハードウェアアクセラレータHA1がリソースR4-1を確保しなければ処理が継続できないため、優先順位ビットpriorityに1を設定する。なお、上記のように、リクエスト者PE0とリクエスト主体となるデバイスHA1とが異なってもよい。選択ユニット4は、リソースR4-1に係るリソースレジスタ10のリソースグループビットgid_rs及びリクエスト者PE1,PE0からのリクエストに係るリクエストレジスタ11のリクエストグループビットgid_rqから、リクエスト主体となるデバイスPE1,HA0の属するグループG0と、リソースR4-1の属するグループG0とが同じであることを確認する。一方で、選択ユニット4はリクエスト主体となるデバイスHA0にリソースR4-1に係る調停結果として、競合が発生していることを通知する。ここで、優先順位ビットpriorityに0を設定しているプロセッサPE1には競合が発生していることを通知しない。このように、優先順位ビットpriorityに0を設定しているデバイスPE1に競合の発生を通知しないことにより、デバイスPE1の処理に影響を与えずにすむ。そして、ハードウェアアクセラレータHA1はこの調停結果の情報を、例えば競合が解決されるまで実行可能な処理を実施したり、電力をセーブしたりする判断材料とする。ここで、選択ユニット4は、リソースR4-1の属するグループG0と同じグループG0のリクエスト主体となるデバイスPE1,HA0に係るリクエストであるため、所有者PE0への解放要求を通知しない。なお、解放要求の通知はこの条件に限定されない。例えば、優先順位ビットpriorityが1のときに、グループが同じであるか否かに関わらず所有者に解放要求を通知してもよい。なお、解放要求が通知されない場合、そのリソースの所有者がそのリソースを不要となり解放するまで待つこととなる。つまり該当の処理が終わるまで例えば、ケースが切り替わるまで解放しないことが明らかである場合には、解放要求の通知をしないこととしてもよい。プロセッサPE0は処理結果をリソースR4-1に格納した後、リソースR4-1を解放する。このとき、プロセッサPE0は同一グループG0内のリクエスト主体となるデバイスPE1,HA1への解放とするために、リソースR4-1のリソースレジスタ10の各ビットを、gid_rs=0、rqid_rs=PE0、owner=0←1と更新して、解放する。このように、同じグループG0内のリクエスト主体となるデバイスPE1,HA1への解放の場合、リソースグループビットgid_rsは未設定に更新しない。すなわち、このときのリソースR4-1は空きグループG15には属しない。なお、このようにリソースグループビットgid_rsが空きグループG15を介さずにリソースR4-1が解放されたときに、調停システム4は、例えばビットownerが0になっていることからリソースR4-1が解放されたことを確認することができる。解放されたリソースR4-1は、第0グループG0を示す識別子gid=0がリソースグループビットgid_rsに設定されており、リクエストグループビットgid_rqが示す第0グループG0に属する各リクエスト者PE1,HA1から所定期間内に受けたリクエストに対して調停されることとなる。選択ユニット4は調停の結果として、優先順位ビットpriorityが1であるハードウェアアクセラレータHA1をリソースR4-1の所有者に決定し、リソースR4-1のリソースレジスタ10の設定を、gid_rs=0、rqid_rs=HA1←PE0、owner=1←0と更新する。その後、選択ユニット4はハードウェアアクセラレータHA1にリソースR4-1が確保されたことを通知する。このようにして、ハードウェアアクセラレータHA1によってリソースR4-1は確保される。以上のように、同じグループG0内のリクエスト主体となるデバイスPE1,HA1への解放の場合、リソースグループビットgid_rsを空きグループG15を示す値に更新しないことにより、リソースR4-1を同じグループG0内で割り付けし、交換することができる。これにより、リソースR4-1を他のグループG1~G4のリクエスト主体となるデバイスリクエスト者PE2,PE3,HA0,HA2から保護することができる。B-2-2.リソースR4-1の所有者の変更の他の例リソースR4-1の所有者がプロセッサPE0からハードウェアアクセラレータHA1に変更される状況の他の例を以下に説明する。なお、上記のB-2-1と同一事項に関しては説明を省略する。プロセッサPE1は、リソースR4-1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=PE1、priority=1、rid=R4-1を設定する。プロセッサPE0は、リソースR4-1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=0、rqid_rq=HA1、priority=1、rid=R4-1を設定する。すなわち、この例では、プロセッサPE1も優先順位ビットpriorityに1を設定しているものとする。選択ユニット4は、リクエスト主体となるデバイスHA1,PE1にリソースR4-1に係る調停結果として、競合が発生していることを通知する。プロセッサPE0は処理結果をリソースR4-1に格納した後、リソースR4-1を解放する。このとき、プロセッサPE0はハードウェアアクセラレータHA1への解放とするために、リソースR4-1のリソースレジスタ10の各ビットを、gid_rs=0、rqid_rs=HA1←PE0、owner=0←1と更新して、解放する。このように、リソースR4-1の解放先を指定したい場合、デバイスPE0は解放先として指定するデバイスHA1をリクエスト者識別ビットrqid_rsに設定する。ここでは、所定の優先順位として、リクエスト主体となるデバイスHA1,PE1に係るリクエストレジスタの優先順位ビットpriorityは両方ともに1であるが、リクエスト者識別ビットrqid_rsに設定されたリクエスト主体となるデバイスHA1が優先される。したがって、選択ユニット4は調停の結果として、リソースR4-1の所有者をハードウェアアクセラレータHA1に決定し、リソースR4-1のリソースレジスタ10の設定を、gid_rs=0、rqid_rs=HA1、owner=1←0と更新する。その後、選択ユニット4はハードウェアアクセラレータHA1にリソースR4-1が確保されたことを通知する。一方で、プロセッサPE1にリソースR4-1が確保されなかったことを通知する。このようにして、ハードウェアアクセラレータHA1によってリソースR4-1は確保される。そして、プロセッサPE1はこのリソースR4-1が確保されなかった情報を、例えば競合が解決されるまで実行可能な処理を実施したり、電力をセーブしたりする判断材料とする。なお、この例のように、優先順位ビットpriorityに1が設定されたリクエストが重複した場合、競合発生の通知を受けたリクエスト主体同士で割り付け先にするデバイスである候補デバイスを決定し、これらのリクエスト主体のうちのいずれか1つがリクエスト者識別ビットrqid_rsに、決定した候補デバイスを示す識別子を設定してもよい。また、例えば、選択ユニット4の動作をモニタリングするプロセッサPE0~PE3を用意し、優先順位が同じである等の理由により、選択ユニット4がリソースの割り付けをしない期間が一定以上経過したとき、このモニタリングするプロセッサPE0~PE3が、優先するデバイスPE0~PE3,HA0~HA2を決定し、リクエストされているリソースR0~R6,HA0~HA2のリクエスト者識別ビットrqid_rsにその決定したデバイスPE0~PE3,HA0~HA2を示す識別子を設定してもよい。また、プロセッサPE0は、処理結果をリソースR4-1に格納する前に、リソースR4-1のリクエストを行っているが、処理結果を格納した後に、リクエストを行ってもよい。その場合、リクエスト者識別ビットrqid_rsを設定するプロセッサPE0のリクエストが優先されるため、リクエスト主体となるデバイスHA1,PE1へのリソースR4-1に係る競合の発生の通知はなくてもよい。<B-3.予約用グループG3へのリソースR6の確保>ここで、プロセッサPE3は、未使用のグループであるG3を予約グループとして使用するものとする。プロセッサPE3は、リソースHA1に対するリクエストとして、リクエストレジスタ11の各ビットに、gid_rq=3、rqid_rq=PE3、priority=0、rid=HA1を設定する。同様に、リソースR1,R6に対するリクエストとして、それぞれリクエストレジスタ11の各ビットに、gid_rq=3、rqid_rq=PE3、priority=0、rid=R1及び、gid_rq=3、rqid_rq=PE3、priority=0、rid=R6を設定する。ケース1において、リソースR6は空きグループG15に属するため、リクエスト者リクエスト主体となるデバイスPE3がリクエストするグループG3に関係なく所定期間内に発生したリクエストに対して調停が行われる。ここで、ケース1からケース2にかけてリソースR6に対するリクエストはプロセッサPE3からのみであるため、競合は発生しない。したがって、選択ユニット4は、調停の結果としてリソースR6の所有者をプロセッサPE3に決定し、リソースR6のリソースレジスタ10の設定を、gid_rs=3←未設定、rqid_rs=PE3←未設定、owner=1←0と更新する。その後、選択ユニット4はプロセッサPE3にリソースR6が確保されたことを通知する。このようにして、プロセッサPE3によってリソースR6は予約グループG3に確保される。一方で、ケース1において、リソースHA1はプロセッサPE1に確保され、リソースR1はハードウェアアクセラレータHA1に確保されている。すなわち、競合が発生している。選択ユニット4は、リクエストレジスタ11の優先順位ビットpriorityが0であるため、リクエスト主体となるデバイスPE3にリソースHA1,R1に競合が発生していることを通知しない。また、リクエスト主体となるデバイスPE3が属するグループG3が、リソースHA1,R1が属するグループG0と異なっているものの、リクエストレジスタ11の優先順位ビットpriorityが0であるため、所有者PE1、HA1に解放要求を通知しない。これにより、所有者PE1,HA1の処理に影響を与えずにすむ。したがって、ケース1からケース2にかけては、予約グループG3へのリクエストに対して、リソースR6のみがプロセッサPE3により予約グループG3に確保される。図7はケース1からケース2への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース1においては、リソースR6が空きグループG15に属しており、ケース1からケース2への移行に伴い空きグループG15に属するリソースはなくなっている。<C.ケース2からケース2’への移行に係る動作>ケース2’とは、ケース2からケース3への移行に係る途中の状態を示しているものとする。図4に示すように、ケース2’では、リソースHA1,R1のそれぞれの所有者がデバイスPE3,HA1からプロセッサPE3に変更されている。また、リソースR4-1がハードウェアアクセラレータHA1から解放され、空きグループG15に属するリソースとなっている。また、プロセッサPE3のシステム処理が終了し、リソースHA0,R0が解放され、ともに空きグループG15に属している。<C-1.予約用グループG3へのリソースR1,HA1の確保>グラフィック処理に係るリソースグループrg3は特定リソースビットrg3にあらかじめ設定されており、リソースR1,R6,HA1からなる。プロセッサPE3は、リソースグループrg3に対するリクエストとしてリクエストレジスタ11の各ビットに、gid_rq=3、rqid_rq=PE3、priority=1、rid=rg3を設定する。このように、リソースグループrg3単位でリクエストする場合には、リクエスト者PE3はリクエスト対象ビットridにリソースグループrg3を示す識別子rg3を設定する。すると、リソースグループrg3に係るリソースR1,R6,HA1への一括のリクエストが行われる。また、優先順位ビットpriorityは先ほどの0から1に変更され、優先順位が高くなったものとする。ここで、リソースR6は、予約グループG3に既に確保されているため、実際には、リソースR1,HA1へのリクエストが行われる。ケース2において、ハードウェアアクセラレータHA1はプロセッサPE1に所有されており、リソースR1はハードウェアアクセラレータHA1に所有されている。選択ユニット4は、リクエスト主体となるデバイスPE3に調停結果を示す情報として、リソースR1,HA1の競合が発生したことを通知する。一方で、選択ユニット4は、リソースHA1,R1の解放要求を示す情報をそれぞれの所有者PE1,HA1に通知する。このとき、リクエストグループビットgid_rqが予約用グループG3を示すリクエストであり、かつ、優先順位ビットpriorityが1に設定されているため、選択ユニット4はリソースHA1,R1の所有者PE1,HA1に予約用グループG3を要求先としたリクエストであることを併せて通知する。本実施形態では、上記のように、予約用グループG3を要求先としたリクエストであることをリクエストグループビットgid_rqが予約用グループG3を示しており、かつ、優先順位ビットpriorityが1に設定されている所定の優先順位以上ときに行うものとする。なお、所定の優先順位以上とは、これに限定されず、例えば、リソースグループrg3がリクエスト対象ビットridに設定されているときとしてもよい。プロセッサPE1及びハードウェアアクセラレータHA1は、予約用グループG3を要求先とするリクエストであることを認識し、この情報を解放の判断基準とする。その後、プロセッサPE1及びハードウェアアクセラレータHA1は、それぞれハードウェアアクセラレータHA1及びリソースR1を解放する。これにより、リソースHA1,R1及びハードウェアアクセラレータHA1に確保されていたリソースR4-1は空きグループG15に属するリソースとなる。選択ユニット4は、リソースHA1,R1が空きグループG15に属するリソースとなったことを検出し、これらのリソースHA1,R1を優先して調停する。本実施形態では、リクエストレジスタ11のリクエスト対象ビットridにリソースグループrg0~rg3が設定された場合、調停のときの優先順位が高くなるものとする。選択ユニット4は、調停の結果としてリソースHA1,R1の所有者をプロセッサPE3に決定し、リソースR1のリソースレジスタ10の設定を、gid_rs=3←未設定←0、rqid_rs=PE3←未設定←HA1、owner=1←0←1と更新する。同様に、リソースHA1のリソースレジスタ10の設定を、gid_rs=3←未設定←0、rqid_rs=PE3←未設定←PE1、owner=1←0←1と更新する。次に、ハードウェアアクセラレータHA1がリソースR1を確保する状況について説明する。プロセッサPE3は先ほど確保したリソースR1に係るリソースレジスタ10を、gid_rs=3、rqid_rs=HA1←PE3、owner=0←1と更新する。一方で、ハードウェアアクセラレータHA1は、リソースR1のリクエストに係るリクエストレジスタ11の各ビットに、gid_rq=3、rqid_rq=HA1、priority=1、rid=R1を設定する。選択ユニット4は調停の結果として、リクエスト主体となるデバイスHA1とリソースR1に係るリソースレジスタ10のリクエスト者識別ビットrqid_rsとが等しいハードウェアアクセラレータHA1をリソースR1の所有者HA1と決定し、リソースR1のリソースレジスタ10の設定を、gid_rs=3、rqid_rs=HA1、owner=1←0と更新する。なお、本実施形態では、リソースR1の所有者がプロセッサPE3に一度更新された後でハードウェアアクセラレータHA1に更新されるため、明示的にリソースR1の割り付けを制御している。ケース2’において、システム処理が終了し、プロセッサPE3及びハードウェアアクセラレータHA0は、それぞれ確保していたリソースHA0,R0を解放する。このとき、プロセッサPE3はリソースHA0のリソースレジスタ10の設定を、gid_rs=未設定←2、rqid_rs=未設定←PE3、owner=0←1と更新する。また、ハードウェアアクセラレータHA0はリソースR0のリソースレジスタ10の設定を、gid_rs=未設定←2、rqid_rs=未設定←HA0、owner=0←1と更新する。これにより、ケース2’において、リソースHA0,R0,R4-1が空きグループG15に属するリソースとなる。なお、例えばリソースの不足が顕著ではないような場合に、ハードウェアアクセラレータHA0は、優先順位ビットpriorityに1が設定されたリクエストが発生するまで、リソースR0の解放を待つこととしてもよい。<D.ケース2’からケース3への移行に係る動作>上記のようにケース2からケース2’を介したケース3への移行において、リソースグループrg3のすべてのリソースR1,R6,HA1が予約グループG3に確保されグラフィック処理に使用可能となり、かつ、プロセッサPE3がシステム処理を終了しているため、プロセッサPE3はグラフィック処理を実施するために、リソースR1,R6,HA1のリソースグループビットgid_rsを一括して3から2に更新する。具体的には、リソースHA1のリソースレジスタ10はgid_rs=2←3、rqid_rs=PE3、owner=1となり、リソースR1のリソースレジスタ10の設定は、gid_rs=2←3、rqid_rs=HA1、owner=1となり、リソースR6のリソースレジスタ10の設定は、gid_rs=2←3、rqid_rs=PE3、owner=1となる。更新が終了した後、プロセッサPE3及びハードウェアアクセラレータHA1は第2グループG2において、グラフィック処理を実行する。図8はケース2からケース3への移行に伴って行われた調停後のリソースレジスタの各ビットの値を示している。ケース2においては、空きグループG15に属するリソースはなく、ケース2からケース3への移行に伴い空きグループG15にはリソースR0,R4-1,HA0が属している。以上のように、予約用グループG3を設けて、グラフィック処理1つの処理に必要なリソースR1,R6,HA1を予約用グループG3を用いてリクエストすることにより、一括して所定の機能の処理本実施形態では、グラフィック処理に使用するリソースR1,R6,HA1を確保することができる。これにより、例えば1つの機能の処理に使用する複数のリソースR1,R6,HA1をまとめてリクエストするデバイスPE3HA1にとって利便性が高まるとともに、機能の処理に使用する所定数以上すべてのリソースR1,R6,HA1を一括確保することによりリソースR0~R6,HA0~HA2の利用率が上がる。また、リソースR1,R6,HA1がすべて使用可能となったところでリソースR1,R6,HA1のリソースグループビットgid_rsを一括して更新してから、機能処理グラフィック処理を実施することにより、グループG3を再度未使用の予約用グループG3として活用することができる。また、リソースグループrg0~rg3を用いたリクエストの優先順位を上げることと予約グループG3の活用とを併用することにより、機能処理に使用するリソースR1,R6,HA1を一括して優先順位を上げて予約グループG3に確保することができる。これにより、機能処理に使用するリソースR1,R6,HA1を一括して確保する時間を短縮することができる。なお、リソースR0~R6,HA0~HA2の異常が所有者PE0~PE3,HA0~HA2や選択ユニット4により検出された場合には、所有者PE0~PE3,HA0~HA2又は選択ユニット4は異常があるリソースR0~R6,HA0~HA2のリソースレジスタ10のエラービットerrorを1に設定し、選択ユニット4はビットownerを1に設定するものとしてもよい。そして、所有者PE0~PE3,HA0~HA2や選択ユニット4によって正常になったことが確認された場合、所有者PE0~PE3,HA0~HA2や選択ユニット4がエラービットerrorを0に設定し、選択ユニット4がビットownerを0に設定することによってリソースR0~R6,HA0~HA2が再度リクエストを受けることができる状態となるようにしてもよい。これにより、異常があるリソースR0~R6,HA0~HA2は、異常状態が正常になるまでリクエスト主体となるデバイスリクエスト者PE0~PE3,HA0~HA2から隔離され、正常になった時点でリクエストを受けることができる。また、上記の説明では、プロセッサPE3はグラフィック処理を実施するために、リソースR1,R6,HA1のリソースグループビットgid_rsを一括して3から2に更新した後にグラフィック処理を実行するものとしたが、更新を行わずに予約グループG3においてグラフィック処理を実行してもよい。また、本実施形態では、映像処理などの機能を1つの機能として記載いたが、例えば映像処理の機能を複数に分割してそれぞれを1つの機能として考えてもよい。また、特定リソースビットrg2,rg3は、それぞれ映像処理、グラフィック処理の実行に必要なリソースグループを示しているが、例えば音声処理やシステム処理のような他の処理の実行に必要なリソースグループを示す特定リソースビットを作成してもよい。また、予約用グループ、空きグループの作成は本実施形態に限定されない。例えば、未使用の別のグループG4を予約用グループ又は空きグループとして使用作成してもよい。また、複数の予約用グループを作成してもよい。また、予約グループ、空きグループは既存の未使用のグループを使ってもいいし、新規に作成してもよい。また、本実施形態では、優先順位ビットpriorityよりもリクエスト者識別ビットrqid_rsの方が優先されるが、優先順位は使用するシステム等に応じて設定を変更することが可能であり、例えば、リクエスト者識別ビットrqid_rsよりも優先順位ビットpriorityの優先順位が高くてもかまわない。また、本実施形態では、レジスタ5は選択ユニット4に備えられているものとして説明したがこれに限定されない。例えば、選択ユニット4の外部にあるレジスタを活用してもよい。また、所有ビットownerは、選択ユニット4が設定するものとしたが、これに限定されない。例えば、リソースR0~R6,HA0~HA2の所有者PE0~PE3,HA0~HA2が設定してもよい。"