複数のタスクが共用する共用資源を利用するためのロックの取得を前記タスクに許可するか否かを示す第1のロック情報に従って、前記タスクによるロックの取得を制御する制御部と、前記タスクによるロックの取得要求が競合しているか否かを判別する判別部とを有し、前記制御部は、前記判別部により前記ロックの取得要求が競合していると判別された場合には、競合発生時におけるロックの取得を許可するか否かを示す第2のロック情報に従って、前記タスクによるロックの取得を制御することを特徴とするロック制御装置。前記制御部は、現在取得されているロックの状態が、当該ロックを取得したタスク以外にも共用資源の参照を認める共用状態である際に、ロックを取得したタスクのみが共用資源を利用することができる排他状態でのロックの取得を他のタスクが要求した場合には、当該他のタスクに前記排他状態でのロックの取得を許可するとともに、前記共用状態でロックを取得したタスクがロックを解放するまでの間、前記他のタスクによる共用資源の利用を待機させることを示す前記第1のロック情報に従うことを特徴とするロック制御装置。前記制御部は、現在取得されているロックの状態が前記排他状態である際に、他のタスクが前記共用状態でのロックの取得を要求した場合には、前記取得されているロックの状態を前記排他状態に保ったまま、前記他のタスクによる前記共用資源の参照を許可することを示す前記第2のロック情報に従うことを特徴とする請求項1に記載のロック制御装置。前記判別部は、前記共用状態でロックを取得したタスクが、所定の時間が経過するまでの間、前記排他状態でロックを取得したタスクによるロックの解放を待機した場合には、競合が発生したと判別することを特徴とする請求項1~3のいずれか1つに記載のロック制御装置。前記判別部は、前記ロックの状態が共用状態である際に前記排他状態でロックを取得したタスクが存在し、かつ、前記共用状態のロックを取得したタスクが再度共用状態でロックの取得を要求した場合には、競合が発生したと判別することを特徴とする請求項1~3のいずれか1つに記載のロック制御装置。前記判別部は、前記ロックの状態が共用状態である際に前記排他状態でロックを取得したタスクが存在する際に、新たなタスクが前記共用状態によるロックの取得を要求した場合には、当該新たなタスクが他にも前記共用状態でロックを取得しているか否かを判別し、ロックを取得していると判別した場合には、競合が発生したと判別することを特徴とする請求項1~3のいずれか1つに記載のロック制御装置。タスクを実行する情報処理装置によって実行されるロック制御プログラムであって、複数のタスクが共用する共用資源を利用するためのロックの取得を前記タスクに許可するか否かを示す第1のロック情報に従って、前記タスクによるロックの取得を制御し、前記タスクによるロックの取得要求が競合しているか否かを判別し、前記ロックの取得要求が競合していると判別した場合には、競合発生時におけるロックの取得を許可するか否かを示す第2のロック情報に従って、前記タスクによるロックの取得を制御することを特徴とするロック制御プログラム。タスクを実行する情報処理装置によって実行されるロック制御方法であって、複数のタスクが共用する共用資源を利用するためのロックの取得を前記タスクに許可するか否かを示す第1のロック情報に従って、前記タスクによるロックの取得を制御し、前記タスクによるロックの取得要求が競合しているか否かを判別し、前記ロックの取得要求が競合していると判別した場合には、競合発生時におけるロックの取得を許可するか否かを示す第2のロック情報に従って、前記タスクによるロックの取得を制御することを特徴とするロック制御方法。しかしながら、現在のロックが共用モードである際に排他モードでのロック取得を認める技術では、同一のタスクが重複してロックを取得することができる場合には、デッドロックが発生してしまうという問題があった。図17は、デッドロックの発生を説明するための図である。図17に示す例では、タスク30とタスク31によるロックの取得処理について、上方向から下方向に向かって処理が進むものとする。図17中Aに示すように、タスク30は、ロックのモードが解放状態である際に、ロックを共用モードで取得しようとした場合には、図17中Bに示すように、ロックを共用モードで取得する。次に、図17中Cに示すように、タスク31は、タスク30がロックを共用モードで取得している際に、自身が排他モードでロックを取得しようとした場合には、図17中Dに示すように、排他モードでロックを取得する。また、タスク31は、共用資源の利用を行わずに、タスク30によるロックの解放を待つ。ここで、図17中Eに示すように、タスク30が共用モードでロックを重複して取得しようとした場合には、現在のロックのモードが排他モードであるので、図17中Fに示すように、タスク30はタスク31によるロックの解放を待つ。この結果、タスク30がタスク31によるロックの解放待ちとなり、タスク31がタスク30によるロックの解放待ちとなるので、図17中Gに示すようにタスク30とタスク31との処理が進まず、デッドロックが発生してしまう。なお、このようなデッドロックの発生を防止するため、同一のタスクによる重複したロックの取得を禁止する手法が考えられる。しかし、同一のタスクによる重複したロックの取得が行えない場合には、各タスクが取得したロックのモードを記憶し、重複したロックの取得を省略する論理を各タスクに組み込むため、実装が煩雑になる。また、各タスクは、それぞれ別々に開発されることが多いため、同一のタスクによる重複したロックの取得の回避を徹底することが困難である。本願に開示の技術は、上述した問題に鑑みてなされたものであって、デッドロックを回避する。一つの側面では、タスクによる共用資源を利用するためのロックの取得を許可するか否かを示す第1のロック情報に従って、タスクによるロックの取得を制御するロック制御装置である。また、ロック制御装置は、タスクによるロックの取得要求が競合しているか否かを判別し、ロックの取得要求が競合していると判別した場合は、競合発生時におけるロックの取得を許可するか否かを示す第2のロック情報に従って、ロックの取得を制御する。一つの側面では、デッドロックを回避する。以下に添付図面を参照して本願に係るロック制御装置、ロック制御プログラムおよびロック制御方法について説明する。以下の実施例1では、図1を用いて、ロック制御装置を有するリソース管理装置の一例を説明する。図1は、実施例1に係るリソース管理装置を説明するための図である。なお、リソース管理装置1は、複数のタスクが共用する複数の共用リソースの管理を行う管理装置である。図1に示すように、リソース管理装置1は、非対称マトリックス記憶部10、一時マトリックス記憶部12、ロック管理情報記憶部14、ロック制御装置20を有する。また、非対称マトリックス記憶部10は、非対称マトリックス11を有し、一時マトリックス記憶部12は、一時マトリックス13を有する。また、ロック管理情報記憶部14は、ロック管理情報15を有する。また、ロック制御装置20は、ロック要求処理部21、競合判定部22、ロック解放処理部23を有する。非対称マトリックス記憶部10は、共用リソースを利用するためのタスクによるロックの取得を許可するか否かを示す非対称マトリックス11を有する。具体的には、非対称マトリックス記憶部10は、あるタスクが現在取得しているロックのモードと新たにタスクが取得を要求したロックのモードとの組にロック取得の可否を対応付けたマトリックスである非対称マトリックス11を有する。図2は、非対称マトリックスの一例を説明するための図である。図2に示すように、非対称マトリックス11は、各行に現在取得されているロックのモードが割当てられており、各列に新たにタスクが取得を要求したロックのモードが割当てられている。ここで、図2中の排他モードとは、ロックを取得したタスクのみがリソースを利用するロックのモードであり、共用モードとは、ロックを取得したタスク以外にも共用リソースの参照を認めるロックのモードである。なお、図2中の解放状態とは、ロックを取得していたタスクがリソースのロックを解放した際に、同じリソースのロックを取得しているタスクが他に存在していない状態を示す。なお、ロックを解放できるのは、解放するロックを取得したタスクのみである。また、図2中のNは、新たなタスクによるロックの取得を許可しない旨を示し、Yは、ロックの取得を要求したタスクによるロックの取得を許可する旨を示す。また、図2中のY待ちは、ロックの取得を要求したタスクによるロックの取得を認めるとともに、現在ロックを取得しているタスクがロックを解放するまでロックの取得を要求したタスクによる共用リソースの利用または参照を待機させる旨を示す。つまり、図2に示す例では、非対称マトリックス11は、あるタスクが現在取得しているロックのモードが排他モードである際に、他のタスクが取得を要求したロックのモードが排他モードである場合には、ロック取得を要求したタスクによるロックの取得を許可しない旨を示す。また、非対称マトリックス11は、あるタスクが現在取得しているロックのモードが排他モードである際に、他のタスクが取得を要求したロックのモードが共用モードである場合には、ロック取得を要求したタスクによるロックの取得を許可しない旨を示す。また、非対称マトリックス11は、あるタスクが現在取得しているロックのモードが共用モードである場合には、他のタスクが取得を要求したロックのモードに係らず、ロック取得を要求したタスクにロックの取得を許可する旨を示す。ただし、非対称マトリックス11は、あるタスクが現在取得しているロックのモードが共用モードである際に、他のタスクが取得を要求したロックのモードが排他モードである場合には、以下の制約をタスクに課す旨を示す。すなわち、非対称マトリックス11は、ロック取得を要求したタスクの排他モードによるロックの取得を許可するとともに、現在のロックを取得したタスクがロックを解放するまで、ロック取得を要求したタスクによる共用リソースの利用を待機させる旨を示す。図1に戻って、一時マトリックス記憶部12は、共用リソースに対するロック取得の要求が競合している際にロックの取得を許可するか否かを示す一時マトリックス13を有する。ここで、ここで、競合とは、以下の状態を示す。すなわち、あるタスクが共用モードでのロックの取得を要求し、他のタスクが排他モードでのロックの取得を要求し、その後、共用モードでロックの取得を要求したタスクが、共用モードで重複するロックの取得を再度要求した状態を言う。具体的には、一時マトリックス記憶部12は、非対称マトリックス11と同様に、あるタスクが現在取得しているロックのモードと他のタスクが新たに取得を要求したロックのモードとの組にロック取得の可否を対応付けた一時マトリックス13を有する。図3は、一時マトリックスの一例を説明するための図である。なお、図3中Y排他モードのままとは、新たなタスクによるロック取得を許可するとともに、現在取得されているロックのモードを排他モードに保持する旨を示す。つまり、一時マトリックス13は、排他モードでロックを取得したタスクを待機させたまま、共用モードでロックの取得を要求したタスクに共用リソースの閲覧を認める旨を示す。図3に示すように、一時マトリックス13は、あるタスクが現在取得しているロックのモードが排他モードであり、他のタスクが取得を要求したモードが排他モードである場合には、ロック取得を要求したタスクにロック取得を許可しない旨を示す。また、一時マトリックス13は、あるタスクが現在取得しているロックのモードが排他モードであり、タスクが取得を要求したロックのモードが共用モードである場合には、ロック取得を要求したタスクに共用モードでのロック取得を許可する旨を示す。ただし、一時マトリックス13は、あるタスクが現在取得しているロックのモードが排他モードであり、タスクが取得を要求したロックのモードが共用モードである場合には、以下の制約をタスクに課す旨を示す。すなわち、一時マトリックス13は、あるタスクが現在取得しているロックのモードを排他モードに保ったまま、ロックの取得を要求したタスクに共用モードでのロックの取得を許可する旨を示す情報を有する。つまり、一時マトリックス13は、ロックの取得を要求したタスクに、共用リソースの参照を許可する旨を示す情報を有する。図1に戻って、ロック管理情報記憶部14は、リソース管理装置1が管理する共用リソースに係る現在のロックの状態を示すロック管理情報15を有する。図4は、ロック管理情報の一例を説明するための図である。図4に示す例では、ロック管理情報15は、ロックの状態を示す情報として、ロックのモード、ロック取得待ちキュー、ロック取得済みキュー、ロック解放待ちキューを有する。なお、ロック管理情報記憶部14は、リソース管理装置1が管理する各共用リソースについて、それぞれ個別にロック管理情報15と同様の情報を有する。ここで、ロックのモードとは、ロック管理情報15に対応する共用リソースについて、あるタスクが現在取得しているロックのモードが排他モードであるか共用モードであるか解放状態であるかを示す。つまり、ロックのモードとは、対応する共用リソースについて、現在取得されているロックのモードを示す情報である。また、ロック取得待ちキューとは、対応する共用リソースのロックの取得を待機しているタスクを示す情報である。また、ロック取得済みキューとは、対応する共用リソースのロックを取得しているタスクを示す情報である。また、ロック解放待ちキューとは、対応する共用リソースについて取得されたロックを解放するのを待機しているタスクを示す情報である。例えば、図4に示す例では、ロック管理情報15は、あるタスクが現在取得しているロックのモードが排他モードであることを示す。また、ロック管理情報15は、ロック取得待ちキューに情報を格納しておらず、ロック取得済みキューにタスク4を示す情報とタスク3を示す情報とを有する。また、ロック管理情報15は、ロック解放待ちキューにタスク3を示す情報を有する。なお、ロック管理情報記憶部14は、各共用リソースごとにロック管理情報15と同様のロック管理情報を有する。以下の説明では、ロック管理情報15に関わる共用リソースに対するロックの取得を各タスク2~4が要求するものとする。図1に戻って、ロック制御装置20は、非対称マトリックス11に従って、各タスク2~4によるロックの取得を制御する。また、ロック制御装置20は、各タスク2~4によるロック取得の要求が競合しているか否かを判別し、競合していると判別した場合には、一時マトリックス13に従って、ロックの取得を制御する。以下、ロック制御装置20が有するロック要求処理部21、競合判定部22、ロック解放処理部23について説明する。ロック要求処理部21は、非対称マトリックス記憶部10に記憶された非対称マトリックス11に従って、各タスク2~4によるロックの取得を制御する。また、ロック要求処理部21は、競合判定部22によって競合が発生していると判定された場合には、一時マトリックス13に従って、各タスク2~4によるロックの取得を制御する。具体的には、ロック要求処理部21は、タスク2~4がロックの取得を要求した場合には、取得を要求されたロックのモードが共用モードであるか否かを判別する。そして、ロック要求処理部21は、要求されたロックのモードが共用モードではない場合には、非対称マトリックス11に従って、要求されたロックのモードとロック管理情報15のロックのモードとに応じたロック取得の可否を判別する。一方、ロック要求処理部21は、要求されたロックのモードが共用モードである場合には、競合判定部22の呼び出しを行い、競合が発生しているか否かを判定させる。そして、ロック要求処理部21は、競合判定部22から競合が発生していると通知された場合には、一時マトリックス13に従って、要求されたロックのモードとロック管理情報15のロックのモードとに応じたロック取得の可否を判別する。また、ロック要求処理部21は、競合判定部22から競合が発生していないと通知された場合には、非対称マトリックス11に従って、ロック取得の可否を判別する。ここで、ロック要求処理部21は、ロック取得の可否を判別する場合には、ロック管理情報15のロックのモードを、あるタスクが現在取得しているロックのモードとして判別する。また、ロック要求処理部21は、判別したロックのモードと要求されたロックのモードとの組に対応付けられたロック取得の可否を、非対称マトリックス11または一時マトリックス13から参照する。そして、ロック要求処理部21は、参照した結果がNであった場合には、ロック取得を要求したタスクを待ち状態にし、タスクをロック管理情報15のロック取得待ちキューの最後尾に繋ぐ。一方、ロック要求処理部21は、参照した結果がYである場合には、ロック管理情報15のロックのモードを要求されたロックのモードに変更する。また、ロック要求処理部21は、ロックの取得を要求したタスクをロック管理情報15が有するロック取得済みキューの最後尾に繋ぐ。また、ロック要求処理部21は、参照した結果がY待ちである場合は、新たにロック取得を要求したタスクを待ち状態にするととともに、新たにロック取得を要求したタスクをロック管理情報15が有するロック解放待ちキューの最後尾に繋ぐ。さらに、ロック要求処理部21は、ロック管理情報15のロックのモードを新たにロック取得を要求したタスクから要求されたロックのモードに変更する。また、ロック要求処理部21は、参照した結果がY排他モードのままである場合は、ロック管理情報15のロックのモードを変更せずに、新たにロック取得を要求したタスクをロック管理情報15が有するロック取得済みキューの最後尾に繋ぐ。つまり、ロック要求処理部21は、新たにロック取得を要求したタスクに対して、共用モードによるロックを取得させる一方で、ロック管理情報15のロックのモードについては、変更を行わず、排他モードを保持させる。このように、ロック要求処理部21は、あるタスクが現在取得しているロックのモードが共用モードである際に、新たなタスクが排他モードでのロックの取得を要求した場合には、新たなタスクに排他モードでのロックを取得させる。また、ロック要求処理部21は、共用モードでロックを取得したタスクがロックを解放するまで、新たなタスクによる共用リソースの利用を待機させる。また、ロック要求処理部21は、あるタスクが現在取得しているロックのモードが排他モードである際に、既に共用モードでロックを取得したタスクが共用モードで重複したロックの取得を要求した場合には、競合判定部22に競合の有無を判定させる。そして、ロック要求処理部21は、競合判定部22によって競合が発生していると判定された場合には、ロックのモードを排他モードに保ったまま、重複したロックの取得を要求したタスクに共用リソースの参照を許可する。つまり、ロック要求処理部21は、ロック管理情報15のロックのモードを変更することなく、重複したロックの取得を要求したタスクに共用モードでのロック取得を許可する。競合判定部22は、各タスク2~4によるロック取得の要求が競合しているか否かを判定する。具体的には、競合判定部22は、あるタスクが共用モードでロックを取得した際に排他モードでロックを取得して待機しているタスクが存在し、共用モードでロックを取得していたタスクが再度共用モードでロックの取得を要求した場合には、競合が発生したと判定する。詳細には、競合判定部22は、ロック要求処理部21から機能を呼び出された場合には、ロック管理情報15のロックのモードが排他モードであるか否かを判別する。また、競合判定部22は、ロック管理情報15のロックのモードが排他モードである場合には、ロック管理情報15のロック解放待ちキューにタスクが繋がっているか否かを判別する。また、競合判定部22は、ロック管理情報15のロック解放待ちキューにタスクが繋がっていた場合には、新たにロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっているか否かを判別する。そして、競合判定部22は、新たにロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっていた場合には、競合が発生したと判定し、競合発生の旨をロック要求処理部21に通知する。また、競合判定部22は、ロック管理情報15のロックのモードが排他モードではなく、ロック管理情報15のロック解放待ちキューにタスクが繋がっていない場合には、競合が発生していないと判定し、その旨をロック要求処理部21に通知する。また、競合判定部22は、新たにロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっていない場合には、競合が発生していないと判定し、その旨をロック要求処理部21に通知する。ロック解放処理部23は、共用リソースの利用や参照を終えたタスクがロックを解放した場合には、ロックの解放を待っていたキューにロックを取得させる。具体的には、ロック解放処理部23は、共用リソースの利用や参照を行っていたタスクがロックを解放した場合には、ロック管理情報15のロック取得済みキューからロックを解放したタスクを削除する。また、ロック解放処理部23は、ロック管理情報15のロック取得済みキューに繋げられたタスクがまだ存在する場合には、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在するか否かを判別する。そして、ロック解放処理部23は、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在すると判別した場合には、ロック解放待ちキューのタスクの待ち状態を解放する。つまり、ロック解放処理部23は、ロック解放待ちキューに繋げられたタスクに共用リソースの利用や参照を実行させる。一方、ロック解放処理部23は、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在していないと判別した場合には、そのまま処理を終了する。また、ロック解放処理部23は、ロック管理情報15のロック取得済みキューにタスクが存在しない場合には、ロック管理情報15のロックのモードを解放状態に変更する。また、ロック解放処理部23は、ロック取得待ちキューに繋げられたタスクの待ち状態を解放し、タスクに対してロックの取得を再度要求させる。次に、ロック制御装置20が有するロック要求処理部21、競合判定部22、ロック解放処理部23が実行する処理の一例について説明する。以下の例では、タスク4が共用モードでロックを取得している間に、タスク3が排他モードでロックの取得を要求し、その後、タスク4が共用モードで重複したロックの取得を要求する例について説明する。例えば、ロック要求処理部21は、ロック管理情報15のロックのモードが解放状態である際に、タスク4が共用モードによるロックの取得を要求した場合には、競合判定部22を呼び出し、競合が発生しているか否かを判定させる。このような場合には、ロック管理情報15のロックのモードが排他モードではないため、競合判定部22は、競合が発生していないと判定し、その旨をロック要求処理部21に通知する。このため、ロック要求処理部21は、非対称マトリックス11を参照し、現在のロックのモードである解放状態とタスク4が取得を要求した共用モードとの組に対応付けられたロック取得の可否がYであることを判別する。そして、ロック要求処理部21は、ロック管理情報15のロックのモードを共用モードに変更し、タスク4をロック管理情報15のロック取得済みキューに繋ぐ。タスク4は、ロック取得済みキューに繋がれたタスクのうち、一番最初のタスクとなるので、共用リソースの参照を行う。次に、ロック要求処理部21は、タスク3が排他モードでロックの取得を要求した場合には、非対称マトリックス11を参照する。そして、ロック要求処理部21は、タスク4が現在取得しているロックのモードである共用モードとタスク3が要求した排他モードとの組に対応付けられたロック取得の可否がY待ちであることを判別する。このため、ロック要求処理部21は、タスク3を待ち状態にするとともに、タスク3をロック管理情報15のロック解放待ちキューに繋ぐ。また、ロック要求処理部21は、ロック管理情報15のロックのモードをタスク3が要求したロックのモードである排他モードに変更する。つまり、この時点では、ロック管理情報15のロック取得済みキューには、1番目にタスク4が繋がっており、2番目にタスク3が繋がっている。次に、ロック要求処理部21は、タスク4が共用モードで重複したロックの取得を要求した場合には、競合判定部22を呼び出し、競合が発生しているか否かを判定させる。このような場合には、競合判定部22は、ロック管理情報15のロックのモードが排他モードであり、かつ、ロック解放待ちキューにタスク3が繋がっており、かつ、ロックの取得を要求したタスク4がロック取得済みキューに繋がっていると判別する。このため、競合判定部22は、競合が発生していると判定し、競合が発生している旨をロック要求処理部21に通知する。このため、ロック要求処理部21は、一時マトリックス13を参照し、ロック管理情報15が示す排他モードとタスク4が取得を要求した共用モードとの組に対応付けられたロック取得の可否がY排他モードのままであることを判別する。このため、ロック要求処理部21は、ロック管理情報15のロック取得済みキューの最後尾にタスク4を繋げる。つまり、ロック要求処理部21は、ロック管理情報15のロックのモードを変更せず、ロック管理情報15のロック取得済みキューのみにタスク4を繋げる。ここで、ロック管理情報15のロック取得済みキューには、タスク3とタスク4が繋がっているが、タスク3は、待機しているため、共用リソースの利用を行わない。一方、タスク4は、共用リソースの参照を行い、共用リソースの参照が終了した場合には、ロックを解放する。すると、ロック解放処理部23は、タスク4をロック取得済みキューから削除し、ロック解放待ちキューのタスク3の待ち状態を解放する。このため、タスク3は、排他モードで共用リソースを利用し、その後、ロックを解放する。図5は、ロックのモードの遷移を説明するための図である。なお、図5に示す例では、上から下に向かって、タスク4が共用モードでロックの取得を要求し、その後、タスク3が排他モードでロックの取得を要求し、さらにその後、タスク4が共用モードで重複したロックの取得を要求した例である。また、図5中のロックのモードとは、ロック管理情報15のロックのモードである。図5中Hに示すように、タスク4が共用モードのロックの取得を要求する。このような場合には、ロック制御装置20は、図5中Iに示すように、タスク4に共用モードのロックを取得させる。また、ロック制御装置20は、ロックのモードを共用モードに遷移させる。次に、図5中Jに示すように、タスク3が排他モードでのロックの取得を要求する。このような場合には、ロック制御装置20は、図5中Kに示すように、タスク3に排他モードのロックを取得させるとともに、タスク4によるロックの解放まで共用リソースの利用を待機させる。また、ロック制御装置20は、ロックのモードを排他モードに遷移させる。次に、図5中Lに示すように、タスク4が共用モードでの重複したロックの取得を要求する。このような場合には、ロック制御装置20は、競合が発生したと判定し、一時マトリックス13に従って、ロック取得の可否を判断する。この結果、ロック制御装置20は、図5中Mに示すように、ロックのモードを排他モードに保持したまま、タスク4に共用モードでの重複したロックを取得させる。この結果、タスク4は、共用リソースを参照し、図5中Nおよび図5中Oに示すように、重複したロックを解放する。すると、図5中Pに示すように、タスク3は、共用リソースを排他モードで利用する。その後、図5中Qに示すように、タスク3は、共用リソースの利用を終了し、ロックを解放する。この結果、ロック制御装置20は、ロックのモードを解放状態に遷移させる。上述したように、ロック制御装置20は、競合が発生していない場合には、非対称マトリックス11に従って、ロックの取得を制御し、競合が発生している場合には、一時マトリックス13に従って、ロックの取得を制御する。このため、ロック制御装置20は、競合が発生したことによるデッドロックを防ぐことができる。例えば、ロック要求処理部21、競合判定部22、ロック解放処理部23とは、電子回路である。ここで、電子回路の例として、ASICApplicationSpecificIntegratedCircuitやFPGAFieldProgrammableGateArrayなどの集積回路、またはCPUCentralProcessingUnitやMPUMicroProcessingUnitなどを適用する。また、非対称マトリックス記憶部10、一時マトリックス記憶部12、ロック管理情報記憶部14とは、RAMRandomAccessMemory、ROMReadOnlyMemory、フラッシュメモリflashmemoryなどの半導体メモリ素子などの記憶装置である。[処理の流れ]次に、図6~8を用いて、ロック制御装置20が有するロック要求処理部21、競合判定部22、ロック解放処理部23が実行する処理の流れを説明する。まず、図6を用いて、ロック要求処理部21が実行する処理の流れを説明する。図6は、実施例1に関わるロック要求処理部が実行する処理の流れを説明するための図である。ロック要求処理部21は、タスク2~4がロックの取得を要求したことをトリガとして、処理を開始する。まず、ロック要求処理部21は、各タスク2~4が取得を要求したロックのモードが共用モードであるか否かを判別するステップS101。そして、ロック要求処理部21は、各タスク2~4が取得を要求したロックのモードが共用モードである場合にはステップS101肯定、競合判定部22を呼び出し、競合が発生しているか否かを判定させるステップS102。次に、ロック要求処理部21は、競合判定部22によって競合が発生していると判定されたか否かを判別しステップS103、競合が発生している場合には、ステップS103肯定、一時マトリックス13を参照するステップS104。つまり、ロック要求処理部21は、ロック管理情報15のロックのモードと各タスク2~4が取得を要求したロックのモードとの組に対応付けられたロック取得の可否を一時マトリックス13から参照する。一方、ロック要求処理部21は、各タスク2~4が取得を要求したロックのモードが共用モードではない場合にはステップS101否定、非対称マトリックス11を参照するステップS105。また、ロック要求処理部21は、競合が発生していない場合にはステップS103否定、非対称マトリックス11を参照するステップS105。つまり、ロック要求処理部21は、ロック管理情報15のロックのモードと各タスク2~4が取得を要求したロックのモードとの組に対応付けられたロック取得の可否を非対称マトリックス11から参照する。次に、ロック要求処理部21は、非対称マトリックス11又は一時マトリックス13の参照結果がNであるか否かを判別するステップS106。そして、ロック要求処理部21は、参照結果がNではなかった場合にはステップS106否定、参照結果がY待ちであるか否かを判別するステップS107。また、ロック要求処理部21は、参照結果がY待ちであった場合にはステップS107肯定、ロックの取得を要求したタスクを待ち状態にするとともにステップS108、ロック管理情報15のロック解放待ちキューに繋ぐステップS109。なお、ステップS108およびステップS109の処理を実行する順番は逆でもよい。次に、ロック要求処理部21は、参照結果がY排他モードのままであるか否かを判別するステップS110。そして、ロック要求処理部21は、マトリックスの参照結果がY排他モードのままではないと判別した場合にはステップS110否定、ロック管理情報15のロックのモードを変更するステップS111。具体的には、ロック要求処理部21は、ロック管理情報15のロックのモードを各タスク2~4が取得を要求したロックのモードに変更する。その後、ロック要求処理部21は、ロックの取得を要求したタスクをロック管理情報15のロック取得済みキューに繋ぎステップS112、処理を終了する。一方、ロック要求処理部21は、非対称マトリックス11または一時マトリックス13の参照結果がY待ちではないと判別した場合にはステップS107否定、参照結果がY排他モードのままであるか否かを判別するステップS110。そして、ロック要求処理部21は、参照結果がY排他モードのままであると判別した場合にはステップS110肯定、ロックの取得を要求したタスクをロック取得済みキューに繋ぎステップS112、処理を終了する。また、ロック要求処理部21は、非対称マトリックス11または一時マトリックス13の参照結果がNであると判別した場合にはステップS106肯定、ロックの取得を要求したタスクを待ち状態にするステップS113。そして、ロック要求処理部21は、ロックの取得を要求したタスクをロック管理情報15のロック取得待ちキューに繋ぎステップS114、処理を終了する。なお、ステップS113の処理とステップS114の処理を実行する順序は、逆でもよい。次に、図7を用いて、競合判定部22が実行する処理の流れについて説明する。図7は、実施例1に関わる競合判定部が実行する処理の流れの一例を説明するための図である。競合判定部22は、ロック要求処理部21から機能を呼び出されることによって、処理を開始する。まず、競合判定部22は、ロック管理情報15のロックのモードが排他モードであるか否かを判別するステップS201。また、競合判定部22は、ロック管理情報15のロックのモードが排他モードであると判別した場合にはステップS201肯定、ロック解放待ちキューにタスクが繋がっているか否かを判別するステップS202。そして、競合判定部22は、ロック解放待ちキューにタスクが繋がっていると判別した場合にはステップS202肯定、ロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっているか否かを判別するステップS203。そして、競合判定部22は、ロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっていた場合にはステップS203肯定、競合が発生したと判定するステップS204。その後、競合判定部22は、競合が発生した旨をロック要求処理部21に通知し、処理を終了する。一方、競合判定部22は、ロック管理情報15のロックのモードが排他モードではないと判定した場合にはステップS201否定、競合が発生していないと判定しステップS205、その旨をロック要求処理部21に通知して、処理を終了する。また、競合判定部22は、ロック管理情報15のロック解放待ちキューにタスクが存在しない場合にはステップS202否定、競合が発生していないと判定するステップS205。また、競合判定部22は、ロックの取得を要求したタスクがロック管理情報15のロック取得済みキューに繋がっていない場合にはステップS203否定、競合が発生していないと判定するステップS205。次に、図8を用いて、ロック解放処理部23が実行する処理の流れについて説明する。図8は、実施例1に関わるロック解放処理部が実行する処理の流れの一例を説明するための図である。ロック解放処理部23は、ロックを取得したタスクがロックを解放したことを契機として、処理を開始する。まず、ロック解放処理部23は、ロック管理情報15のロック取得済みキューからロックを解放したタスクを削除するステップS301。次に、ロック解放処理部23は、ロック管理情報15のロック取得済みキューにタスクが繋がっているか否かを判別するステップS302。そして、ロック解放処理部23は、ロック取得済みキューにタスクが繋がっていると判別した場合にはステップS302肯定、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在するか否かを判別するステップS303。そして、ロック解放処理部23は、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在すると判別した場合にはステップS303肯定、ロック解放待ちキューに繋がったタスクの待ち状態を解放するステップS304。その後、ロック解放処理部23は、ロック解放待ちキューからタスクを削除しステップS305、処理を終了する。一方、ロック解放処理部23は、ロック管理情報15のロック取得済みキューに存在する全てのタスクがロック解放待ちキューに存在していないと判別した場合にはステップS303否定、処理を終了する。また、ロック解放処理部23は、ロック取得済みキューにタスクが繋がっていないと判別した場合にはステップS302否定、ロック管理情報15のロックのモードを解放状態に変更するステップS306。次に、ロック解放処理部23は、ロック管理情報15のロック取得待ちキューにタスクが繋がれているか否かを判別するステップS307。そして、ロック解放処理部23は、ロック取得待ちキューにタスクが繋がれていると判別した場合にはステップS307肯定、ロック取得待ちキューに繋がれた先頭のタスクの待ち状態を解放し、ロックの取得を再度要求させるステップS308。その後、ロック解放処理部23は、処理を終了する。また、ロック解放処理部23は、ロック取得待ちキューにタスクが繋がれていないと判別した場合にはステップS307否定、処理を終了する。[実施例1の効果]上述したように、実施例1に関わるロック制御装置20は、非対称マトリックス11に従って、各タスク2~4による共用リソースのロックの取得を制御する。また、ロック制御装置20は、各タスク2~4によるロックの取得要求が競合しているか否かを判定する。そして、ロック制御装置20は、各タスク2~4によるロックの取得要求が競合していると判定した場合には、一時マトリックス13に従って、各タスク2~4による共用リソースのロックの取得を制御する。このため、ロック制御装置20は、デッドロックを回避することができる。すなわち、ロック制御装置20は、各タスク2~4によるロックの取得要求が競合している場合には、デッドロックを回避するように設定された一時マトリックス13に従って、各タスク2~4によるロックの取得を制御する。この結果、ロック制御装置20は、デッドロックを防ぐことができる。また、ロック制御装置20は、同一のタスクによる重複したロックの取得を禁止する論理を各タスクに組み込まずとも、デッドロックを防ぐことができる。このため、ロック制御装置20は、各タスク2~4の実装を容易にすることができる。また、非対称マトリックス11は、ロック管理情報15のロックのモードが共用モードである際に、要求されたロックのモードが排他モードである場合には、以下の処理を実行させる旨を示す。すなわち、非対称マトリックス11は、ロックの取得を要求したタスクに対して、排他モードでのロックの取得を許可するとともに、共用モードでロックを取得したタスクがロックを解放するまで、共用リソースの利用を待機させることを示す。この結果、ロック制御装置20は、非対称マトリックス11を用いて、各タスク2~4によるロックの取得を制御した場合には、以下の効果を奏する。すなわち、ロック制御装置20は、共用モードでのロックの取得を要求するタスクが発生し続けても、排他モードでロックを取得したタスクに、有限な時間内で共用リソースを利用させることができる。また、一時マトリックス13は、ロック管理情報15のロックのモードが排他モードである際に、要求されたロックのモードが共用モードである場合には、以下の処理を実行させる旨を示す。すなわち、一時マトリックス13は、ロックの取得を要求したタスクに対して共用モードでのロックの取得を許可するとともに、ロック管理情報15のロックのモードを排他モードのままにする旨を示す。換言すると、一時マトリックス13は、あるタスクによって現在取得されているロックのモードをそのままに保持するとともに、共用モードでのロックの取得を要求したタスクに、共用リソースの参照のみを許可する旨を示す。このため、ロック制御装置20は、競合発生時に一時マトリックス13に従ってロックの取得を制御した場合には、競合発生時のデッドロックを適切に防ぐことができる。また、ロック制御装置20は、ロック管理情報15のロックのモードが共用モードである際に、排他モードでロックを取得したタスクが存在し、その後、以下の条件を満たした場合には、競合が発生したと判定する。すなわち、ロック制御装置20は、共用モードでロックを取得していたタスクが共用モードで重複するロックの取得を要求した場合には、競合が発生したと判定する。このため、ロック制御装置20は、適切に競合の発生を判定することができる結果、デッドロックを回避することができる。上述したロック制御装置20は、各タスク2~4によるロック取得の要求に応じて、競合が発生しているか否かを判定していた。しかし、実施例は、これに限定されるものではなく、他の方法を用いて、ロック取得の要求が競合しているか否かを判定するものとしてもよい。図9は、実施例2に係るリソース管理装置を説明するための図である。なお、図9中に示す各部1~4、10~15、20~23のうち、実施例1と同様の処理を実行するものについては、図1と同じ符号を付すものとし、その符号での説明を省略する。例えば、実施例2に係るロック制御装置20aは、ロック要求処理部21a、競合判定部22a、ロック解放処理部23を有する。また、ロック制御装置20aは、共用モードでロックを取得したタスクが所定の時間が経過するまでの間、排他モードでロックを取得したタスクによるロックの解放を待機しつづけた場合には、競合が発生したと判定する。つまり、ロック制御装置20aは、所定の時間が経過するまでの間、タスクが待機しつづけた場合には、競合が発生していると判断し、一時マトリックス13に従ってロック取得の可否を判別する。以下、このようなロック制御装置20aが有するロック要求処理部21a、競合判定部22aが実行する処理について説明する。図10は、実施例2に係るロック要求処理部が実行する処理の流れを説明するためのフローチャートである。なお、図10に示す処理のうち、ステップS401~S407については、図6に示すステップS101~107と同一の処理であるので、説明を省略する。実施例2に係るロック要求処理部21aは、マトリックスの参照結果がY待ちであった場合にはステップS407肯定、タスクを待ち状態にするステップS408。次に、ロック要求処理部21aは、マトリックスの参照結果がY排他モードのままであるか否かを判別するステップS409。そして、ロック要求処理部21aは、マトリックスの参照結果がY排他モードのままである場合にはステップS409肯定、処理を終了する。一方、ロック要求処理部21aは、マトリックスの参照結果がY排他モードのままではない場合にはステップS409否定、タスクから要求されたロックのモードに応じて、ロック管理情報15のモードを変更するステップS410。また、ロック要求処理部21aは、マトリックスの参照結果がNである場合にはステップS406肯定、タスクを待ち状態にしステップS411、処理を終了する。なお、ロック要求処理部21aは、マトリックスの参照結果がY待ちではない場合にはステップS407否定、マトリックスの参照結果がY排他モードのままであるか否かを判別するステップS409。図11は、実施例2に係る競合判定部が実行する競合判定処理の流れを説明するためのフローチャートである。まず、実施例2に係る競合判定部22aは、ロック管理情報15のロックのモードが排他モードであるか否かを判別するステップS501。そして、競合判定部22は、ロック管理情報15のロックのモードが排他モードである場合にはステップS501肯定、すべての既存タスクによるロックの解放を待機しているタスクが存在するか否かを判別するステップS502。また、競合判定部22aは、ロックの解放を待機しているタスクが存在する場合にはステップS502肯定、ロック管理情報15のロックのモードが排他モードになってから所定の時間が経過したか否かを判別するステップS503。そして、競合判定部22aは、ロック管理情報15のロックのモードが排他モードになってから所定の時間が経過したと判別した場合にはステップS503肯定、次の処理を実行する。すなわち、競合判定部22aは、最後のタスクがロックを共用モードで取得してから所定の時間が経過したか否かを判別するステップS504。その後、競合判定部22aは、最後のタスクがロックを共用モードで取得してから所定の時間が経過したと判別した場合にはステップS504肯定、競合が発生したと判定するステップS505。その後、競合判定部22aは、競合が発生した旨をロック要求処理部21aに通知し、処理を終了する。一方、競合判定部22aは、ロックの解放を待機しているタスクが存在しない場合にはステップS502否定、競合の発生はないと判定しステップS507、その旨をロック要求処理部21aに通知して、処理を終了する。また、競合判定部22aは、ロック管理情報15のロックのモードが排他モードになってから所定の時間が経過していない場合にはステップS503否定、以下の処理を行う。すなわち、競合判定部22aは、一定時間が経過したあとで、後述する定期競合判定処理を起動するように自装置を設定するステップS506。その後、競合判定部22aは、競合が発生していないと判定しステップS507、処理を終了する。また、最後のタスクがロックを共用モードで取得成功してから所定の時間が経過していないと判別した場合にはステップS504否定、一定時間経過後に定期競合判定処理を起動するように自装置を設定するステップS506。図12は、定期競合判定処理を説明するための図である。競合判定部22aは、図11に示すステップS506にて、定期競合判定処理を起動するよう設定した場合には、一定時間経過後に、図12に示す処理を実行する。具体的には、競合判定部22aは、図11に示した競合判定処理図11中ステップS501~507を実行するステップS601。次に、競合判定部22aは、競合が発生したか否かを判定するステップS602。そして、競合判定部22aは、競合が発生したと判定した場合にはステップS602肯定、ロック要求処理部21aを呼び出し、ロック取得待ちの全てのタスクについて、図10に示すロック要求処理を再実行させるステップS603。その後、競合判定部22aは、処理を終了する。また、競合判定部22aは、競合が発生していないと判定した場合にはステップS602否定、処理を終了する。つまり、競合判定部22aは、所定の時間間隔で図11および図12に示す処理を実行し、競合が発生しているか否かを判定する。[実施例2の効果]上述したように、実施例2に係るロック制御装置20aは、排他モードでロックを取得したタスクによるロックの解放を、共用モードでロックを取得したタスクが、所定の時間が経過するまでの間、待機した場合には、競合が発生したと判定する。つまり、ロック制御装置20aの競合判定部22aは、排他モードでロックを取得したタスクと共用モードでロックを取得したタスクとが、所定の時間が経過するまでの間、待機した場合には、競合が発生したと判定する。このため、ロック制御装置20aは、競合が発生したか否かを容易に判定することができる。つまり、ロック制御装置20aは、今までロックの取得を要求してきたタスクの情報をロック管理情報15として記憶させなくとも、競合の発生を判定することができる。この結果、ロック制御装置20aは、リソース管理装置1の回路規模を抑えるとともに、容易に実装を行う事ができる。これまで、実施例について説明したが、実施例は、上述した実施例以外にも様々な異なる形態にて実施されてよいものである。そこで、以下では実施例3として本発明に含まれる他の実施例を説明する。1競合判定について上述した競合判定部22は、あるタスクが共用モードでロックを取得している際に、他のタスクが排他モードでロックを取得し、さらに、共用モードでロックを取得していたタスクが共用モードで重複するロックの取得を要求した場合には、競合が発生したと判定した。また、上述した競合判定部22aは、あるタスクが排他モードでロックを取得し、他のタスクが共用モードでロックを取得してから、所定の時間が経過するまでの間、両タスクが待機した場合には、競合が発生したと判定した。しかし、実施例は、これに限定されるものではなく、様々な方法を用いて、競合が発生した否かを判定するようにしてもよい。以下、図13、図14を用いて、競合が発生したか否かを判定する処理の他の例について説明する。図13は、競合が発生したか否かを判定するための処理の一例を説明するためのフローチャート1である。なお、図13に示す処理は、図7に示す処理を一般化した処理に対応する。また、以下の説明では、実施例3に係るロック制御装置20bは、ロック要求処理部21b、競合判定部22b、ロック解放処理部23を有するものとする。例えば、実施例3に係る競合判定部22bは、ロック管理情報15のロックのモードが排他モードであるか否かを判別するステップS701。そして、競合判定部22bは、ロック管理情報15のロックのモードが排他モードである場合にはステップS701肯定、全ての既存タスクのロック解放を待っているタスクが存在するか否かを判別するステップS702。そして、競合判定部22bは、全ての既存タスクのロック解放を待っているタスクが存在する場合にはステップS702肯定、ロックを要求したタスクが既にロックを共用モードで取得済みであるか否かを判別するステップS703。その後、競合判定部22bは、ロックを要求したタスクが既にロックを共用モードで取得済みであった場合にはステップS703肯定、競合が発生したと判定するステップS704。一方、競合判定部22bは、ロック管理情報15のモードが排他モードでない場合にはステップS701否定、競合が発生していないと判定するステップS705。同様に、競合判定部22bは、全ての既存タスクのロック解放を待機しているタスクが存在しない場合にはステップS702否定、競合が発生していないと判定するステップS705。また、競合判定部22bは、ロックを要求したタスクが既にロックを共用モードで取得済みではない場合にはステップS703否定、競合が発生していないと判定するステップS705。このような競合判定部22bを有するロック制御装置20bは、競合の発生を判定することができる。結果として、ロック制御装置20bは、デッドロックを適切に防ぐことができる。他の例では、競合判定部22bは、ロックのモードが共用モードである際にあるタスクが排他モードでロックを取得し、さらに他のタスクが共用モードでロックの取得を要求した場合には、以下の判定をおこなう。すなわち、競合判定部22bは、競合モードでロックの取得を要求したタスクが他にも共用モードでロックを取得しているか否かを判別する。そして、競合判定部22bは、競合モードでロックの取得を要求したタスクが他にも共用モードでロックを取得していると判定した場合には、競合が発生したと判定してもよい。図14は、競合が発生したか否かを判定するための処理の一例を説明するためのフローチャート2である。なお、図14中のステップS801、S802、S804、S805については、図7中のステップS201、S202、S204、S205と同じ処理であるため、説明を省略する。競合判定部22bは、全ての既存タスクのロック解放を待っているタスクが存在する場合にはステップS802肯定、ロックの取得を要求したタスクが既に何らかのロックを取得済みであるか否かを判別するステップS803。そして、競合判定部22bは、ロックの取得を要求したタスクが既に何らかのロックを取得済みである場合にはステップS803肯定、競合が発生したと判定するステップS804。このように、競合判定部22bは、ロックの取得を要求したタスクが他にもロックを取得済みであるか否かを判別することで、競合が発生したか否かを判定する。この結果、ロック制御装置20bは、ロック管理情報15にロックを取得した全タスクをロック取得済みキューに繋げずとも、各キューがロックを取得したか否かを記憶させればよいので、リソース管理装置1の回路規模を抑え、実装を容易にすることができる。2マトリックスについて図2に示す非対称マトリックス11は、ロック取得の可否を示す情報としてY、Y待ち、Nが格納されていた。また、図3に示す一時マトリックス13は、ロック取得の可否を示す情報としてY排他モードのまま、Nが格納されていた。しかし、これらロック取得の可否を示す情報は、あくまで例示であり、上述した機能を果たすための情報であれば、任意の情報を格納することができる。3プログラムところで、上記した実施例1~3では、ハードウェアを利用して各種の処理を実現する場合を説明した。しかし、実施例はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図15を用いて、実施例1に示したロック制御装置20と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図15は、ロック制御プログラムを実行するコンピュータの一例を説明するための図である。図15に例示されたコンピュータ100は、RAMRandomAccessMemory120、HDDHardDiskDrive150がバス170で接続される。また、図15に例示されたコンピュータ100は、CPUCentralProcessingUnit140がバス170で接続される。HDD150には、ロック制御プログラム151があらかじめ保存される。CPU140が、HDD150からロック制御プログラム151を読み出して実行することによって、RAM120には、非対称マトリックス121、一時マトリックス122が展開される。なお、非対称マトリックス121は、図1の非対称マトリックス11と同じマトリックスであり、一時マトリックス122は、図1の一時マトリックス13と同じマトリックスである。また、CPU140がロック制御プログラム151を読み出して実行することによって、CPU140では、ロック要求処理プロセス141、競合判定プロセス142、ロック解放処理プロセス143が機能するようになる。なお、各プロセス141~143は、図1に示した各部21~23と同様の機能を発揮する。また、各プロセス141~143は、実施例2または実施例3に係る各部と同等の機能を発揮するようにすることも可能である。なお、本実施例で説明したロック制御プログラムは、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスクFD、CD-ROMCompactDiscReadOnlyMemory、MOMagnetoOpticalDisc、DVDDigitalVersatileDiscなどのコンピュータで読取可能な記録媒体に記録される。また、このプログラムは、コンピュータによって記録媒体から読み出されることによって実行することもできる。