JPH09198265A - マルチスレッド型プログラミング環境における共用資源への並行同時アクセスを自動的に管理する方法及びそのための装置 - Google Patents

Abstract

(57)【要約】 【課題】 プログラム内のアプリケーション展開や制
御の正常な流れを損なうことなく、シングルアクセス資
源に対するロックをどのスレッドからでも自動的に設定
しかつ解放することができる汎用性があって使いやすい
機構を提供すること。 【解決手段】 プログラムの１つのスレッドに、そのス
レッドが現在その資源の使用を必要とするか否かに関わ
らず、その資源に関連するロックの所有権を与えること
によって、プログラムの他のスレッドにまさる優先権を
与える。これら他のスレッドは、資源の使用が必要なと
き、そのことを優先スレッドに知らせるようになってい
る。優先スレッドは、資源を使用し終え、別のスレッド
が資源を使用するために待っていることを検知すると、
その資源についての資源ロックを解放する。優先スレッ
ドは、資源を解放した後、自動的に資源ロックを要求す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、単一のプログラム
が同時アクティブな複数のスレッドを持つことが可能な
コンピュータシステムに関し、より詳しくは、同じプロ
グラムの複数スレッド間における共用資源を管理する方
法及びそのための装置に関する。

【０００２】

【従来の技術】実行中のプロセスは、メモリ、モデム及
びプリンタのような資源を利用する。これらの資源をフ
ルに利用するために、複数のプロセスが資源を共用する
ことを可能にするオペレーティングシステムが開発され
てきた。そのために、ユーザは、各ワードプロセッシン
グプログラム毎に１台のプリンタを購入しなければらな
らい訳ではなく、並列実行される複数のワードプロセッ
シングプログラムによって共用されるプリンタを１台だ
け買えばよい。

【０００３】上に述べたように、資源は共用することが
できても、多くの資源は、特定の時点で２つ以上のエン
ティティによって使用することはできない。一時に２つ
以上のエンティティにより信頼性をもって使用すること
ができない資源を、以下シングルアクセス資源と称す
る。たとえば、ほとんどのプリンタは、一時に２つ以上
のワードプロセッサ用の文書をプリントすることはでき
ないので、シングルアクセス資源である。その結果、多
くのオペレーティングシステムには、２つ以上のプロセ
スが同時にシングルアクセス資源にアクセスするのを防
ぐ機構が組み込まれている。

【０００４】コンピュータシステムの処理能力をより十
分に利用するために、コンピュータプログラムの中に
は、特定のタスクを実行するための「ワーカースレッ
ド」を生成するよう設計されたものがある。ワーカース
レッドは、メインプログラムと同じプログラムの一部で
あるが、メインプログラムの実行とは独立に実行するよ
うスケジュールされ、そのように実行することができる
命令のシーケンスである。マルチスレッド型システムに
おいては、メインプログラム自体もスレッド（「メイン
スレッド」）と見なされる。

【０００５】事象駆動型のマルチスレッド型プログラム
は、通常、ユーザのユーザインタフェース制御との対話
動作がシステムによって検出されたことをユーザに知ら
せるためのビジュアルフィードバックを生成する役割が
与えられる。たとえば、ユーザがコントロールパネル上
のボタンを選択した場合、ディスプレイをそのボタンが
押されたことを示すように更新するのは、通常、コント
ロールパネルに関連するプログラムのメインスレッドの
役割である。

【０００６】初期化されると同時に、事象駆動型のマル
チスレッド型プログラムは、一般に、ウィンドウシステ
ムにユーザインタフェースオブジェクトを表示させた
後、関心のある事象（関心事象）についてオペレーティ
ングシステムに知らせる。そのような事象は、一般に、
ユーザインタフェースオブジェクトとのユーザ対話を含
む。

【０００７】メインスレッドプログラムは、オペレーテ
ィングシステムに関心事象について知らせた後、オペレ
ーティングシステムによって中断状態になる。通常、メ
インスレッドは、関心事象の１つが起きるまで中断状態
に保たれる。関心事象が起きると同時に、オペレーティ
ングシステムはその事象を記述したメッセージをマルチ
スレッド型プログラムに対応するメッセージ待ち行列に
入れ、メインスレッドを起動する。メインスレッドは、
ユーザにビジュアルフィードバックを与えるようディス
プレイを更新する。さらに、メインスレッド自体がボタ
ンの選択に関連する何らかのタスクを実行し、あるいは
そのタスクを実行するためのワーカースレッドを生成す
る場合もある。

【０００８】同じプログラムの多くのスレッドが同時に
アクティブになることもある。コンピュータシステムに
２つ以上のプロセッサがある場合、種々のスレッドが同
時に実行されることさえある。たとえば、マルチスレッ
ド型プログラムのメインスレッドは、メッセージを受け
取ったとき、そのメッセージを処理するための新しいワ
ーカースレッドを生成する場合がある。また、第２のメ
ッセージを受け取ると、メインスレッドはその第１のメ
ッセージを処理するための第２のワーカースレッドを生
成することがある。これらのメインスレッド、第１のワ
ーカースレッド及び第２のワーカースレッドは、全て同
時にアクティブになり得る。

【０００９】それらの各スレッドは、実行しようとする
タスクによって決まるそれぞれの資源を要求する。たと
えば、上記の第１及び第２のスレッドは、両方ともユー
ザに表示されるビジュアル出力を発生するかもしれな
い。その場合は、両方のスレッドがウィンドウシステム
への接続を要求することになろう。

【００１０】一部の環境においては、マルチスレッド型
プログラムはウィンドウシステムとの接続を１つしか割
り当てられない場合がある。そのために、情報を表示し
たいプログラムの種々のスレッドがその接続を共用しな
ければならない。しかしながら、ウィンドウシステムへ
の接続は、一般には、シングルアクセス資源になってい
る。

【００１１】たとえば、スレッドの文脈切換えが起きた
とき、第１のワーカースレッドがその接続を介して表示
コマンドを送る途中であると仮定する。そして、スレッ
ドの文脈切換え後、第２のワーカースレッドがその接続
を介して表示コマンドを送り始めるとする。このような
状況が起きると、ウィンドウシステムは、ガーベッジが
見えるだけである。ウィンドウシステムはマルチスレッ
ド型プログラムをキルしたり、あるいはクラッシュして
ガーベッジに応答することがある。

【００１２】従って、複数のプログラムが共用シングル
アクセス資源に同時にアクセスしないようにしなければ
ならないのと全く同様に、同じプログラムのスレッドが
共用シングルアクセス資源に同時にアクセスするのを防
がなければならない。残念ながら、大部分のオペレーテ
ィングシステムは、１つのプログラム内のスレッドによ
る資源への同時アクセスを防ぐようにはなっていない。
そのために、複数のスレッド間で共用資源へのアクセス
を制御するための機構を与える責任は、通常アプリケー
ションの開発者が担うことになる。

【００１３】プログラムのスレッド間で共用資源アクセ
スを管理する問題の標準的な解決方法は、各共用シング
ルアクセス資源毎に「ロック」を設けることである。一
つの典型的なロックは、オーナとある状態を有すると共
に、共用資源と対応づけられたデータ構造である。一時
には、必ず１つのスレッドだけがシングルアクセス資源
にアクセスするようにするためには、アプリケーション
の開発者は、各スレッドがその資源にアクセスする前に
その資源に関連するロックの制御権を得るように各スレ
ッドを設計しなければならない。そのために、各スレッ
ドは、ロックが他のスレッドによって保持されている
と、そのロックが解放されるまで待たなければならな
い。全てのスレッドがこのロックの基本要件を考慮して
設計されていないと、シングルアクセス資源が損なわれ
る危険性があり、あるいはプログラムがクラッシュした
り、これらの両方の不具合が起きたりする。

【００１４】上記のようなロック機構を得るためには、
アプリケーション開発者は、通常、プログラムの各スレ
ッドのカスタムコードをそれらのスレッドがロックを必
要に応じて設定し、解放するように書かなければなけれ
ばならない。これは、メインスレッド（事象駆動型プロ
グラムの場合は事象ループを含む）は第三者の開発者に
よってアプリケーション開発者に供給されるベースライ
ブラリの一部であることが多いので、特に難しく、また
退屈な作業である。さらに、一部のソフトウェア開発環
境にあっては、事象ループはアプリケーション開発者か
ら見えないので、アプリケーション開発者はロック関連
の機能性を付加するための書き換えを行うことができな
い。

【００１５】従来のロック機構においては、全てのスレ
ッド（メインスレッドを含む）は、ロックに関連する資
源を使う必要があるときそのロックを要求し、ロックに
関連する資源を使用し終えたときそのロックを解放しな
ければならない。従って、メインスレッドは、メッセー
ジ待ち行列中の全てのマスキングの処理を終了すると、
ウィンドウシステム接続に関連するロックを解放した
後、中断状態になり、より多くのメッセージが利用可能
になるまでその状態に保たれる。メインスレッドが中断
状態にある間は、アクティブのどのワーカースレッドも
そのロックの制御権を得て、対応する資源にアクセスす
ることができる。オペレーティングシステムは、ロック
を待っている全てのスレッドの待ち行列を持ち続ける。
スレッドによってロックが解放されると、オペレーティ
ングシステムはそのロックに関連する待ち行列中のスレ
ッドの１つを選択し、そのロックをその選択したスレッ
ドに与える。

【００１６】図１は、上に述べたような方法により設計
されたロック機構を有するコンピュータシステムにおけ
るある特定の一組の動作のタイミングを示したものであ
る。図１において、時刻Ｔ０では３つのスレッド、すな
わちメインスレッド、ワーカースレッド１及びワーカー
スレッド２がアクティブになっている。最初は、プログ
ラムのメインスレッドがその資源に対するロックを保持
している。時刻Ｔ１では、メインスレッドがそのロック
に関連する資源を使用し終え、従ってロックを解放す
る。また、時刻Ｔ１では、ワーカースレッド２がその資
源を使用する必要があり、そのためにそのロックを要求
する。

【００１７】時刻Ｔ２では、ワーカースレッド２がロッ
クを獲得し、ワーカースレッド１がそのロックを要求す
る。時刻Ｔ３及びＴ４では、ワーカースレッド２が、ワ
ーカースレッド１が中断状態にある間に、そのロックに
関連する資源の使用を必要とするワークを実行し、そし
てロックを解放する。時刻Ｔ５では、ワーカースレッド
１がオペレーティングシステムによって起動され（アク
ティブになり）、ロックを獲得する。

【００１８】時刻Ｔ６では、ワーカースレッド１がその
資源を使ってワークを実行する。また、時刻Ｔ６では、
ワーカースレッド２が再度ロックを要求する。時刻Ｔ７
では、ワーカースレッド１がロックを解放する。時刻Ｔ
８では、メインスレッドがロックを要求し、ワーカース
レッド２がロックを獲得する。時刻Ｔ９では、ワーカー
スレッド１がロックを要求し、ワーカースレッド２がこ
のロックに対応するワークを実行する。時刻１０では、
ワーカースレッド２がロックを解放する。

【００１９】時刻Ｔ１１では、メインスレッドがロック
を要求する。時刻Ｔ１２では、メインスレッドがその資
源を使用する。時刻Ｔ１３では、メインスレッドがロッ
クを解放する。時刻Ｔ１４では、メインスレッドがロッ
クを要求し、ワーカースレッド１がロックを得る。時刻
Ｔ１５では、ワーカースレッド１がこのロックに対応す
る資源が必要なワークを実行する。時刻Ｔ１６では、ワ
ーカースレッド１がロックを解放する。時刻Ｔ１７、Ｔ
１８及びＴ１９では、メインスレッドがロックを獲得
し、そのロックに対応する資源を使用し、次いでロック
を解放する。

【００２０】

【発明が解決しようとする課題】上に述べたようなロッ
ク共用ストラテジは、種々のスレッドによって実行され
るプログラムがユーザに無応答のように見えることがあ
るという大きな短所がある。たとえば、あるワーカース
レッドが資源の制御権を得て、長時間ロックを保持する
と、メインスレッドは、その資源を使いたい他の全ての
スレッドと共に、そのロックを保持するための自己の順
番を待たなければならない。上に述べたように、メイン
スレッドは、通常、プログラムのユーザインタフェース
とのユーザの対話に応答してビジュアルフィードバック
を生成する役割を担う。従って、ユーザは、何らかのア
クションに対するビジュアル応答を、メインスレッドが
ウィンドウシステムへの接続の制御権を獲得するまでの
間待たなければならない場合がある。ユーザは、プログ
ラムから即時のビジュアルフィードバックが得られない
と、プログラムの無欠性に疑念を持ち始めることもあ
る。さらに、複数のワーカースレッドがある場合は、現
在ロックを保持するワーカースレッドがそのロックを解
放したとき、メインスレッドがロックを獲得するための
リストの最上位にないこともある。

【００２１】上に述べたことから、プログラム内のアプ
リケーション展開や制御の正常な流れを損なうことな
く、シングルアクセス資源に対するロックをどのスレッ
ドからでも自動的に設定しかつ解放することができる汎
用性があって使いやすい機構を提供することは、疑いも
なく望まれるところである。また、アプリケーション開
発者がプログラムの事象ループを書き直したり、これに
アクセスしたりする必要なしに、スレッド間でロックを
管理するための機構を提供することも望まれるところで
ある。さらに、ユーザ起動事象とそのユーザ起動事象に
対応するビジュアルフィードバックとの間の遅延ができ
るだけ短くなるようなロック管理ストラテジを提供する
ことも望まれる。

【００２２】

【課題を解決するための手段】本発明は、マルチスレッ
ド型コンピュータプログラムのスレッドがある資源をど
のように共用するかを管理する方法及びそのための装置
にある。本発明によれば、プログラムの１つのスレッド
に、そのスレッドが現在その資源の使用を必要としてい
るかどうかに関わらずその資源に対応するロックを保持
させることによって、そのプログラムの他のスレッドに
まさる優先権を与える。他のスレッドは、資源の使用が
必要なとき、その優先権を有する優先スレッドにそのこ
とを知らせるようになっている。優先スレッドが資源を
使用し終え、他のスレッドがその資源を使用するために
待機していることを検知すると、優先スレッドはその資
源についての資源ロックを解放する。その資源に対する
ロックを解放した後、優先スレッドは自動的にその資源
ロックを要求する。優先スレッド以外のいずれかの非優
先スレッドが資源を使用し終えた後、優先スレッドがそ
の資源を要求していれば、その非優先スレッドは、他の
スレッドがその資源を待っているか否かに関わらず、優
先スレッドに対してその資源を解放する。本発明の一実
施態様によれば、タイマー機構を用いて、いずれかのス
レッドが資源を使用するために待機しているかどうかを
優先スレッドに周期的にチェックさせる。

【００２３】本発明の一態様によれば、マルチスレッド
型プログラムの複数のスレッド間で資源を共用する方法
が得られる。この方法によれば、複数のスレッドの中の
第１のスレッドがその資源に対応する資源ロックを獲得
し、それらの複数のスレッドの中の他のスレッドがその
資源の使用を必要としていることを検知するまで、その
資源ロックを保持する。第１のスレッドは、それらの複
数のスレッドの中の他のスレッドが資源の使用を要求し
ていることを検知すると、その検知に応答してその資源
の使用を全て終了し、資源ロックを解放して要求してい
る他のスレッドがその共用資源にアクセスできるように
し、そして資源ロックを要求する。第１のスレッド以外
の各スレッドは、資源を使用し終えた後、第１のスレッ
ドに対して資源ロックを解放するようになっている。

【００２４】本発明のもう一つの態様によれば、ある資
源に対応する資源ロックを保持する第１のスレッドに他
の１つ以上のスレッドがその資源の使用を必要としてい
ることを知らせる方法が得られる。この方法によれば、
タイマーが起動され、第１のスレッドはそのタイマーに
基づいて周期的にアクティブにされる。第１のスレッド
は、タイマーに基づいてアクティブになると、記憶場所
の値を調べることによって、他のいずれかのスレッドが
その資源の使用を要求しているかどうかを判断する。第
１のスレッド以外の全てのスレッドは、資源の使用を要
求したとき、記憶場所の値を更新するようになってい
る。

【００２５】以下、本発明を添付図面に示す実施形態に
より詳細に説明するが、これらの説明は本発明を限定す
るためのものではなく、図中同じ参照符号は同様の構成
要素・部分を指すものとする。

【００２６】

【発明の実施の形態】

ハードウェアの概要 以下、本発明によるマルチスレッド型プログラムのスレ
ッド間で資源を共用する方法及びそのための装置を実施
形態により詳細に説明する。以下の説明においては、発
明の完全な理解を図るために、説明の便宜上多くの具体
的詳細事項を記載する。しかしながら、当業者にとって
は、本発明がそれらの具体的詳細事項なしで実施可能で
あることは明白であろう。その他の場合においては、本
発明を無用に不明確にすることを避けるため、周知の構
造や装置はブロック図形式により示してある。

【００２７】図２において、符号１００は、本発明の実
施形態を実施することができるコンピュータシステムを
示す。図示のコンピュータシステム１００は、情報を伝
達するためのバスまたはその他の通信手段１０１、及び
バス１０１に接続された情報を処理するための処理手
段、すなわちプロセッサ１０２を有する。コンピュータ
システム１００は、さらに、バス１０１に接続されてい
て情報及びプロセッサ１０２によって実行される命令を
記憶するためのランダムアクセスメモリ（ＲＡＭ）また
はその他の動的記憶装置、すなわち主メモリ１０４を有
する。主メモリ１０４は、プロセッサ１０２による命令
の実行時に一時的変数またはその他の中間情報を記憶す
るために使用することができる。また、コンピュータシ
ステム１００は、プロセッサ１０２用の静的情報及び命
令を記憶するためのバス１０１に接続されたリードオン
リーメモリ（ＲＯＭ）及び／またはその他の静的記憶装
置１０６を有する。バス１０１には、情報及び命令を記
憶するためのデータ記憶装置１０７も接続されている。

【００２８】コンピュータシステム１００には、磁気デ
ィスクまたは光ディスクのようなデータ記憶装置とその
対応するディスクドライブを接続することができる。コ
ンピュータシステム１００は、バス１０１を介してコン
ピュータユーザに情報を表示するためのブラウン管（Ｃ
ＲＴ）のような表示装置１２１を接続することができ
る。通常は、情報及びコマンド選択をプロセッサ１０２
に伝達するために、アルファニューメリック及びその他
のキーを含むアルファニューメリック入力装置またはキ
ーボード１２２がバス１０１に接続される。もう一つの
形のユーザ入力装置として、マウス、トラックボール、
またはカーソル方向キーのような方向情報及びコマンド
選択をプロセッサ１０２に伝達すると共に、表示装置１
２１上のカーソルの動きを制御するためのカーソルコン
トロ−ル１２３が設けられている。この入力装置は、通
常、２軸、すなわち第１の軸（たとえばｘ軸）及び第２
の軸（たとえばｙ軸）における２自由度を有し、平面内
の位置を指定することができる。

【００２９】あるいは、スタイラスまたはペンのような
他の入力装置を用いて表示装置との対話操作を行うこと
もできる。コンピュータ画面上の表示オブジェクトは、
スタイラスまたはペンを用いて表示オブジェクトに触れ
ることによって選択することができる。コンピュータ
は、タッチセンシティブスクリーンを実装することによ
って、その選択を検出する。同様に、ライトペンと光感
応スクリーンを用いて表示オブジェクトを選択すること
もできる。このように、このような装置は、マウスまた
はトラックボールを装備したシステムの場合のように
「ポイント・アンド・クリック」操作ではなく、選択位
置と選択を単一操作として検出する。スタイラス及びペ
ンベースの入力装置やタッチスクリーン及び光感応スク
リ−ンは、当技術分野において周知である。このような
システムでは、符号１２２で示すようなキーボードなく
し、全てのインタフェースを筆記具（ペンのような）と
してのスタイラスを介して行い、書いたテキストを光学
文字読取り（ＯＣＲ）技術を用いて解釈するようにする
ことも可能である。

【００３０】この実施形態においては、本発明は、コン
ピュータシステム１００を用いて、スレッドが以下にさ
らに詳細に説明する技術的方法に従って資源を共用する
ようにしたマルチスレッド型プログラムを実行しようと
するものである。

【００３１】ロック移管ストラテジの改善 上に述べたように、メインスレッドは、通常、ユーザと
の対話を制御するプログラムの部分になっている。メイ
ンスレッドがウィンドウシステムとの接続を使用するの
に待たなければならない時間が長いほど、ユーザにはプ
ログラムの応答が遅いように見える。従って、本発明
は、ビジュアル表示に関連する資源に関して他のスレッ
ドにまさる優先権をメインスレッドに与えるロック制御
ストラテジを提供するものである。従って、ユーザがボ
タンをクリックすると、プログラムは、即時のビジュア
ルフィードバックをユーザに与えて、プログラムの「応
答性がよい」ように感じさせる。

【００３２】この実施形態のロック移管ストラテジによ
れば、メインスレッドは、明確にロックを解放するよう
要求されない限り、ビジュアル出力に関連するロックの
制御権を常時持ち続ける。このように、メインスレッド
は、たとえ休止状態にあるときでも、他のスレッドがロ
ックを要求していなければ、ロックを保持する。この点
は、全てのスレッドが、ロックに関連する資源の使用を
必要とするタスクを終了すると同時にロックを解放する
図１に示す従来のロック移管方式と明確に異なる。

【００３３】本発明により得られるロック移管の技術に
よれば、ワーカースレッドは、資源の使用を必要とする
とき、資源にアクセスしたいということをメインスレッ
ドに知らせる。メインスレッドは、その都合がよいと
き、資源に関連するロックをワーカースレッドに対して
解放する。従って、メインスレッドは、資源を使用中で
あれば、その資源を必要とするタスクを終了してからそ
の資源に関連するロックを解放する。メインスレッド
は、資源を使用していなければ、ワーカースレッドがそ
の資源を使いたいという通知を受け取ると同時に、その
資源に関連するロックを即時解放する。

【００３４】メインスレッドがロックを解放すると、ワ
ーカースレッドはそのロックを得て、資源にアクセスす
ることができる。しかしながら、メインスレッドは、ロ
ックを解放するとすぐにロックを要求する。ワーカース
レッドは、資源を使用し終えると、他のスレッドもロッ
クの制御権を要求しているか否かに関わらず、ロックを
解放して、メインスレッドに戻す。

【００３５】図３は、上記のロック移管の技術を実装し
たシステムにおけるある特定の一連の動作のタイミング
を示したものである。図３において、時刻Ｔ０で、メイ
ンスレッドがロックを保持しており、ワーカースレッド
１がロックを要求する。時刻Ｔ１で、メインスレッドは
ロックを解除し、ワーカスレッド２がロックを要求す
る。時刻Ｔ２では、メインスレッドがロックを要求し、
ワーカースレッド１がロックを得る。ここで、メインス
レッドのロック要求は、ロック解放後自動的に行われ、
メインスレッドが現在そのロックに関連する資源を必要
としているか否かには依存しないということに留意すべ
きである。

【００３６】時刻Ｔ３では、ワーカースレッド１がその
ロックに関連する資源を使用するワークを実行し、その
後時刻Ｔ４でロックを解放する。時刻Ｔ５では、メイン
スレッドがロックを獲得する。ここで、メインスレッド
は、ワーカースレッド２がメインスレッドよりも前から
ロックを要求しているにもかかわらず、ロックを得てい
るということに留意する必要がある。メインスレッドの
ロック要求は、常に、他の全ての待ち状態の要求にまさ
る優先権を与えられている。

【００３７】メインスレッドは、時刻Ｔ６で資源を必要
とする何らかのワークを実行する。また、時刻Ｔ６で
は、ワーカースレッド１もロックを要求する。メインス
レッドは、時刻Ｔ７で資源を使用し終え、ロックを解放
する。ここで、このロック解放は、メインスレッドがそ
の資源使用を終了することに応答して自動的に行われる
訳ではないということに留意すべきである。メインスレ
ッドは、（１）メインスレッドが資源を使用し終え、か
つ（２）他のスレッドがその資源を使用したいという待
ち状態の要求が少なくとも１つあるときに限り、ロック
を解放する。時刻Ｔ７で資源を使用したいという待ち状
態の要求がなければ、メインスレッドは時刻Ｔ７でロッ
クを解放しないはずである。

【００３８】時刻Ｔ８で、メインスレッドがロックを要
求し、ワーカースレッド２がロックを獲得する。上に述
べたように、メインスレッドは、メインスレッドがロッ
クを解放する都度、自動的にロックを要求する。時刻Ｔ
９で、ワーカースレッド２が資源を使用するタスクを実
行する。時刻Ｔ１０で、ワーカースレッド２がロックを
解放する。時刻Ｔ１１で、メインスレッドがロックを獲
得する。ここで、メインスレッドは、たとえワーカース
レッド１の要求がメインスレッドの要求より前に出され
た場合でも、ワーカースレッド１より先にロックを獲得
し、メインスレッドはそのロックに関連する資源を必ず
しも使用する必要はないということに留意すべきであ
る。

【００３９】時刻Ｔ１２で、メインスレッドは、資源が
必要な何らかのワークを実行する。時刻Ｔ１３で、メイ
ンスレッドがロックを解放する。時刻Ｔ１４では、ワー
カースレッド１がロックを獲得する。時刻Ｔ１５で、ワ
ーカースレッド１が資源を使用するタスクを実行する。
時刻Ｔ１６では、ワーカースレッド１がロックを解放す
る。時刻Ｔ１７では、メインスレッドがロックを獲得す
る。時刻Ｔ１７では、メインスレッドが資源の使用が必
要な何らかの処理を実行する。

【００４０】以上説明したロック移管ストラテジは、メ
インスレッドが受ける遅延が短くなるという点で、従来
のロックストラテジより優れている。メインスレッドが
受ける遅延の短縮は、ユーザが受ける遅延の短縮に直結
する。たとえば、時刻Ｔ９で、ユーザ事象が起きると、
メインスレッドは時刻Ｔ１２でその事象に応答すること
ができる。従来のロック移管ストラテジならば、ワーカ
ースレッド１が時刻Ｔ１１でロックを獲得し、メインス
レッドは、ワーカースレッド１がそのタスクを終了し
て、その資源に対するロックを解放するまでユーザ事象
に応答することができないはずである。

【００４１】指示型ロック移管 上述のロック移管ストラテジでは、ワーカースレッド
は、他のスレッドが資源ロックを待っている場合でも、
ロックの制御権をメインスレッドに戻すことができなけ
ればならない。本発明の一実施形態によれば、これは、
ロックの状態を、ロックを待っているスレッドの中のど
のスレッドがロックへのアクセス権を持つことができる
かを決定する「鍵穴」として用いることにより可能にな
る。

【００４２】具体的に説明すると、各ロックにはそれぞ
れ何らかの状態が付随している。この実施形態において
は、スレッドがロックへのアクセスを要求するとき、そ
のスレッドは、その要求にに「キー」を入れることがで
きる。スレッドがロックを解放するとき、そのスレッド
は、解放後にそのロックが取るべき状態を指定すること
ができる。ロックがある特定の状態で解放されると、以
後、そのロックはそのロックの状態に対応するキーの入
ったスレッドによってしか獲得されない。ロックを要求
しても、このロックの現在の状態に対応しないキーを指
定したスレッドは、そのロックの制御権を与えられな
い。

【００４３】本発明の一実施形態によれば、上記の状態
及びキーは、どちらも単に数値であってもよい。そのよ
うな実施形態においては、ロック管理機構は、ロックに
関連する状態値と一致するキー値が入っている要求を検
討するだけ済む用に構成することができる。

【００４４】上記のような機構を用いて、ワーカースレ
ッドは、ロックをメインスレッドに渡すための第１の状
態でロックを解放するようになっており、メインスレッ
ドは、ロックをワーカースレッドに渡すための第２の状
態でロックを解放する。ワーカースレッドは、第２の状
態に対応するキーをそれらのロック要求に入れて送るよ
うになっており、メインスレッドは、ロックを要求する
とき、第１の状態に対応するキーを送る。このような条
件下で、ロックは、いずれかのワーカースレッドによっ
て解放された後、たとえそのロックを待っている他のワ
ーカースレッドがあっても、メインスレッドに戻すこと
ができる。

【００４５】登録に基づく通信機構 上述のロック共用ストラテジは、ワーカースレッドとメ
インスレッドとの間で通信を行うための機構が必要であ
る。具体的にいうと、メインスレッドは、（１）ワーカ
ースレッドがロックを必要としているとき、及び（２）
ロックを保持していたワーカースレッドがそのロックを
解放したとき、それらを検知しなければならない。本発
明の一実施形態によれば、多くのオペレーティングシス
テムで与えられる登録機能を用いて、上述のロック移管
ストラテジを実施するのに必要なメインスレッドとワー
カースレッドとの間の通信を確保することができる。

【００４６】詳しく説明すると、メインスレッドは、各
シングルアクセス共用資源毎に、ファイル記述子または
ネットワーク接続上のソケットのようなエンティティイ
ンジケータをオペレーティングシステムに登録すること
ができる。エンティティインジケータを登録することに
よって、メインスレッドは、オペレーティングシステム
に、そのエンティティインジケータに関連するエンティ
ティへのアクセスはコンピュータプログラムにとっての
関心事象であるということを知らせる。従って、メイン
スレッドがファイル記述子を登録すると、そのファイル
記述子に関連するファイルがアクセスされたとき、オペ
レーティングシステムはその事象を確認するメッセージ
を生成し、そのメッセージをメインスレッドの事象待ち
行列に入れ、メインスレッドを起動する。

【００４７】メインスレッドがエンティティインジケー
タを登録していると、ワーカースレッドは、ロックを必
要としていることをメインスレッドを起動する動作を実
行することによってメインスレッドに知らせる。たとえ
ば、ファイル記述子を用いる場合は、ワーカースレッド
はファイルに書込みを行う。また、ネットワーク接続を
用いる場合は、ワーカースレッドはネットワーク接続を
介して何らかの情報を送る。

【００４８】オペレーティングシステムは、ワーカース
レッドによって実行された動作に応答して、その事象を
表すメッセージをメインスレッドの事象待ち行列に入
れ、メインスレッドを起動する。メインスレッドは、そ
のメッセージを読むことによって、ワーカースレッドが
登録エンティティに対応する資源を使用する必要がある
ということを知らされる。

【００４９】ファイル記述子またはネットワークソケッ
トを用いてスレッド間の通信を行うことの利点は、登録
機構は通常オペレーティングシステムによって提供され
るため、メインスレッドがこの通信をサポートするのに
必要な機能性を最小限に抑えられるということである。
従って、メインスレッドは該当するマスキングを受け取
ると同時に該当するロックを解放するようになっていさ
えすればよい。

【００５０】上記の登録による方法は、ワーカースレッ
ドの数が多いと、効率が悪くなる。ワーカースレッドが
たくさんある場合は、事象をトリガーする動作を実行す
るのに必要な処理資源の量が顕著に大きくなる。たとえ
ば、ファイルまたはソケットを書き込むのは非常に時間
を要する動作である。ロックを共用するワーカースレッ
ドが沢山ある場合は、実際のタスクの実行よりむしろ通
信オーバーヘッドによって多大の時間が費消される。

【００５１】上記の登録に基づく方法の第２の欠点は、
プログラムによって登録できるある種のエンティティイ
ンジケータの数がオペレーティングシステムによってし
ばしば制限されるということである。たとえば、ＵＮＩ
Ｘオペレーティングシステムでは、各プロセスはほんの
少数のファイル記述子しか登録することを許容されな
い。

【００５２】第３の欠点は、オペレーティングシステム
によって、エンティティインジケータがトリガーされた
待ち状態の通知の数がしばしば制限されることである。
ファイルに書き込むか、ネットワーク接続を介して何ら
かの情報を送ることによって共用資源へのアクセスを要
求するワーカースレッドが多数ある場合は、オペレーテ
ィングシステムは、旧い通知を破棄することによって、
新しい通知を入れるための余裕を作る。その結果、メイ
ンスレッドは、待ち状態のワーカースレッド数を把握し
続けられなくなることがある。

【００５３】カウンタに基づく通信機構 図４は、メインスレッド型プログラム４０４のプロセス
空間内に、カウンタ値４０２を記憶するための記憶場所
が割り当てられている本発明の一実施形態を示す。この
カウンタ値の記憶場所に対してロック４０６が設定され
る。このカウンタ値記憶場所に対するロックを以下「カ
ウンタロック」４０６と称し、シングルアクセス共用資
源４０８に関連するロックを「資源ロック」４１０と称
する。

【００５４】４１４及び４１６で示す各ワーカースレッ
ドは、資源４０８にアクセスしたいとき、図６に示すス
テップを実行するようになっている。たとえば、ワーカ
ースレッド４１４が、ある特定のタスクを実行するのに
資源４０８を必要とするものと仮定する。ステップ６０
０で、ワーカースレッド４１４はカウンタロック４０６
を獲得する。ステップ６０２では、ワーカースレッド４
１４はカウンタ値記憶場所のカウンタ値４０２をインク
リメントする。ステップ６０４では、ワーカースレッド
４１４はカウンタロック４０６を解放する。ステップ６
０６では、ワーカースレッド４１４は資源ロック４１０
についての要求を送出する。ステップ６１０では、ワー
カースレッド４１４は中断状態になる。

【００５５】メインスレッド４１８は、（１）メインス
レッドが資源４０８を使用しておらず、かつ（２）１つ
以上のワーカースレッドが資源ロック４１０を要求して
いるとき、資源ロック４１０を解放するようになってい
る。メインスレッド４１８によって実行されるステップ
を図５に示す。ステップ５００で、メインスレッド４１
８はカウンタ４０２をチェックして、いずれかのワーカ
ースレッドが資源ロック４１０を要求しているかどうか
を判断する。カウンタ４０２のノンゼロ値は、現在少な
くとも１つのワーカースレッド４１４がシングルアクセ
ス資源４０８を使用したがっているということをメイン
スレッド４１８に知らせる信号である。カウンタ４０２
の値がゼロの場合、メインスレッドは中断状態になる
（すなわち事象待ち状態を取る）（ステップ５０２）。

【００５６】メインスレッド４１８は、カウンタ４０２
のノンゼロ値を検出すると、資源４０８を使用するタス
クを全て終了する。ステップ５０４は、資源４０８を他
のタスクに渡す前に実行しなければならないクリア動作
を伴う。たとえば、資源４０８がウィンドウシステムと
の接続である場合は、ステップ５０４にはウィンドウサ
ーバ接続を全て解消する動作を含む。ステップ５０６で
は、メインスレッド４１８は、資源ロック４１０の状態
４２０をワーカースレッド４１４及び４１６によって使
用されるキーに対応する状態に設定する。ステップ５０
７では、メインスレッド４１８は、資源４０８に対応す
るフラグ４２２をセットして、メインスレッド４１８が
資源ロック４１０を待っているということを指示する。
ステップ５０８では、メインスレッド４１８は、資源ロ
ックを解放する。

【００５７】ステップ５０９、５１０及び５１１では、
メインスレッド４１８はカウンタロックを得、カウンタ
４０２をデクリメントし、カウンタロックを解放する。
ステップ５１２では、メインスレッド４１８は資源ロッ
クを要求する。オペレーティングシステム４１２は、メ
インスレッド４１の要求４２６を資源ロック要求待ち行
列４２４に入れる。その要求４２６には、メインスレッ
ド４１８が要求４２６を出したエンティティであること
を示す送出者情報４２８及びキー値４３０が含まれる。
メインスレッド４１８は、次に、資源ロック４１０につ
いてのその要求が受け入れられるまで、中断状態にな
る。

【００５８】オペレーティングシステム４１２は、資源
ロック４１０が空いていることを検知すると、そのロッ
ク４１０を要求しているワーカースレッドの１つに対し
てそのロック４１０を認める。具体的にいうと、オペレ
ーティングシステム４１２は、資源ロック要求待ち行列
４２４の中の要求を選択し、その要求中のキー値を資源
ロック４１０の現在の状態４２０と比較する。そして、
キー値がロック４１０の状態４２０と一致すれば、オペ
レーティングシステム４１２はその要求を認める。キー
値が一実施形態においては、４２０と一致しなければ、
オペレーティングシステム４２は他の要求を選択し、上
記のステップを繰り返し実行する。

【００５９】オペレーティングシステム４１２は、この
プロセスを、資源ロック４１０の状態４２０に対応する
キーを有する要求に遭遇するまで続ける。オペレーティ
ングシステム４１２は、資源ロック４１０の状態４２０
に対応するキーを有する要求に遭遇すると、資源要求４
１０をその要求を送出したスレッドに与え、そのスレッ
ドを起動する。

【００６０】不都合なことに、ワーカースレッド４１４
がカウンタ４０２をインクリメントしたとき、メインス
レッド４１８が中断されるかもしれない。さらに、ワー
カースレッド４１４がカウンタロック４０６を獲得する
か、カウンタ４０２をインクリメントしたとき、関心事
象が発生しないと、そのために、メインスレッド４１８
は、中断状態であっても起動されない。その結果、メイ
ンスレッド４１８が中断状態で、関心事象の発生を待っ
ている間、メインスレッド４１８待ちの状態になるた
め、システムの効率が著しく低下することがある。

【００６１】そのような遅延を避けるため、メインスレ
ッド４１８の事象ループを拡張して、資源ロック４１０
を渡すようにという要求の有無をメインスレッド４１８
に周期的にチェックさせるタイマー４３１を含むように
する。具体的にいうと、メインスレッド４１８がタイマ
ー４３１をオペレーティングシステム４１２に登録す
る。タイマー４３１は関心事象を一定間隔で発生する。
タイマー４３１がオフになると、オペレーティングシス
テム４１２はそのタイマー４３１の事象を示すメッセー
ジをメインスレッド４１８の事象待ち行列４３２に入
れ、メインスレッド４１８を起動する。メインスレッド
４１８は、このタイマー事象によって起動されると同時
に、図５を参照して上に説明したステップを実行する。

【００６２】上に述べたように、メインスレッド４１８
によって資源ロック４１０が解放されると、オペレーテ
ィングシステム４１２は、資源ロック４１０の所有権を
シングルアクセス資源４０８を使用するために待ってい
るワーカースレッドの１つに渡す。資源ロック４１０の
所有権を与えられたワーカースレッド４１０は、図７に
示すステップを実行する。

【００６３】ステップ７００では、ワーカースレッド４
１４が資源ロック４１０を得る。ステップ７０２で、ワ
ーカースレッド４１４は、資源４０８を使ってタスクを
実行する。ワーカースレッド４１４は、資源４０８を使
用し終えると、資源４０８を他のスレッドが使用できる
状態に整えるために必要なクリア動作を実行する。ステ
ップ７０４では、ワーカースレッド４１４は資源４０８
に関連するフラグ４２２をチェックして、メインスレッ
ド４１８が資源ロック４１０を待っているかどうかを確
認する。メインスレッド４１８が資源ロック４１０を待
っていることを、フラグ４２２が示している場合には、
ワーカースレッド４１４は資源ロック４１０の状態４２
０をメインスレッド４１８によって使用されるキー４３
０と一致する状態に設定してから（ステップ７０８）、
資源ロック４１０を解放する（ステップ７１０）。メイ
ンスレッド４１８が資源ロック４１０を待っていること
をフラグ４２２が示していない場合は、ワーカースレッ
ド４１４は資源ロック４１０の状態４２０をワーカース
レッドによって使用されるキーと一致する状態に設定し
てから（ステップ７０６）、資源ロック４１０を解放す
る（ステップ７１０）。

【００６４】ワーカースレッド４１４が資源ロック４１
０を解放すると、オペレーティングシステム４１２はロ
ックを得させるために他のスレッドを選択する。上に述
べたように、オペレーティングシステム４１２は、資源
ロック４１０の現在の状態に適合するキーを持つ要求を
検討するだけである。ワーカースレッド４１４が、資源
ロック４１０をメインスレッド４１８によって使用され
るキーに対応する状態に置いたと仮定すると、メインス
レッド４１８だけが資源ロック４１０の状態に一致する
キーを持つ唯一のスレッドになる。従って、オペレーテ
ィングシステム４１２は、資源ロック４１０の所有権を
メインスレッド４１８に与える。

【００６５】オペレーティングシステム４１２は、資源
ロック４１０をメインスレッド４１８に与えた後、メイ
ンスレッド４１８を起動する。メインスレッド４１８
は、起動されると、資源４０８に関連するフラグ４２２
をセットして、メインスレッド４１８は制御ロック４１
０を待っていないということを指示する。

【００６６】システムによっては、オペレーティングシ
ステム４１２が状態／キー比較を行うようになっていな
い場合がある。そのようなシステムでは、オペレーティ
ングシステム４１２は、ワーカースレッド４１４が資源
ロック４１０を解放した後、メインスレッド４１８が資
源ロック４１０を待っていても、資源ロック４１０をメ
インスレッド４１８ではなく別のワーカースレッドに与
えるかもしれない。その場合、オペレーティングシステ
ム４１２は、資源ブロック４１０が与えられたワーカー
スレッドを起動する。

【００６７】このような条件下では、各ワーカースレッ
ドは、実際に資源４０８を使用する前に、メインスレッ
ド４１８が資源ロック４１０を待っていることをフラグ
４２２が指示しているかどうかを確認するようになって
いる。フラグ４２２がメインスレッド４１８が資源ロッ
ク４１０を待っているということを指示している場合
は、ワーカースレッド４１４は、資源４０８を使用する
前に資源ロック４１０を即時解放する。この動作が、フ
ラグ４２２がメインスレッド４１８が資源ロック４１０
を待っているということを指示している間、オペレーテ
ィングシステム４１２により資源ロックを与えられた全
てのワーカースレッドについて繰り返される。その最後
には、オペレーティングシステム４１２は資源ロック４
１０をメインスレッド４１８に与える。

【００６８】前に述べた登録に基づく方法に付随する問
題は、このカウンタに基づく通信機構では回避される。
詳しくいうと、ワーカースレッド４１４が資源４０８を
使いたいということをメインスレッド４１８に知らせる
のに文脈切換えを必要としないので、処理のオーバヘッ
ドの大半が回避される。さらに、アプリケーションの開
発者に与えられるアプリケーションの枠組みでは、タイ
マー４３１の機能性が既に事象ループに組み入れられて
いるかもしれないので、サポートの開発者は、事象ルー
プを書き換える必要はなく、あるいは事象ループにアク
セスする必要さえない。

【００６９】デッドロックを防ぐための直接ロック移管 時には、デッドロックを防ぐために、メインスレッド４
１８が資源ロック４１０をワーカースレッドに直接渡す
ことが必要な場合もある。たとえば、メインスレッド４
１８は、ユーザ事象に応答して、ワーカースレッド４１
４に対して発呼するかもしれない。その場合、メインス
レッド４１８は、ワーカースレッド４１４がそのタスク
を終了するまで中断状態になる。ワーカースレッド４１
４は、ワーカースレッド４１６に何らかのタスクを実行
するよう発呼することができる。ワーカースレッド４１
６によって実行されるタスクは、資源４０８の使用を必
要とすることがある。その場合、ワーカースレッド４１
６は、資源ロック４１０を求める要求を送出し、資源ロ
ック４１０が与えられるまで中断状態になる。

【００７０】上記の状況は、メインスレッド４１８はワ
ーカースレッド４１４がそのタスクを終了するまで、ア
クティブになって資源ロック４１０を解放することはな
く、ワーカースレッド４１４はワーカースレッド４１６
がそのタスクを終了するまで自己のタスクを終了するこ
とはできず、またワーカースレッド４１６はメインスレ
ッド４１８が資源ロック４１０を解放するまでそのタス
クを終了することはできないので、デッドロックにな
る。

【００７１】このようなデッドロックの問題をなくすた
め、メインスレッド４１８は、ワーカースレッドが資源
４０８を使用することを要するような発呼をする前に、
資源ロック４１０を明示的に解放する。メインスレッド
４１８は、資源ロック４１０を明示的に解放した後、資
源ロック４１０を要求する。すると、メインスレッド４
１８は、資源４０８の使用について他のスレッドを排除
することなく、中断状態を取ることができる。

【００７２】資源４０８を使用していたワーカースレッ
ド４１６は、資源４０８を使用し終えると、資源ロック
４１０の状態４２０をメインスレッド４１８によって使
用されるキーに対応する状態に設定する。メインスレッ
ド４１８により呼び出されたワーカースレッド４１４が
そのタスクを終了すると、オペレーティングシステム４
１２はメインスレッド４１８を起動する。このように起
動されたメインスレッド４１８は、資源４１０の制御権
を得る。

【００７３】以上説明した本発明の実施形態において
は、説明の便宜上いろいろな仮定を行った。たとえば、
資源に関する優先権はプログラムのメインスレッドに与
えるものと仮定した。資源がウィンドウシステムとの接
続であり、メインスレッドがユーザの対話動作に応答し
てビジュアルフィードバックを生成する役割を持つ場合
においては、このように仮定する方が望ましい。しかし
ながら、他の条件下においては、資源に関して、特定の
ワーカースレッドにメインスレッドを含む他の全てのス
レッドにまさる優先権を与えることが望ましい場合もあ
る。従って、本発明は、メインスレッドに優先権を与え
る実施形態に限定されるものではない。

【００７４】以上、この明細書では、本発明を特定の実
施形態に関連して説明した。しかしながら、本発明につ
いて、その広義の精神及び範囲を逸脱することなく種々
の修正態様を並びに変更態様を実施することが可能なこ
とは明らかであろう。たとえば、メインスレッドに、資
源ロックを解放するときカウンタをデクリメントさせる
のではなく、資源ロックを与えられたワーカースレッド
が資源を使用する前、またはその後にカウンタをデクリ
メントするようにしてもよい。従って、本願明細書及び
図面は、限定的な意味ではなく、例示説明的な意味にお
いて解釈すべきものである。

【図面の簡単な説明】

【図１】 従来のロック共用ストラテジを用いたロック
方式における典型的な動作シーケンスを示すタイミング
図である。

【図２】 本発明の一実施形態を実施するよう構成する
ことが可能なコンピュータシステムのブロック図であ
る。

【図３】 本発明の一実施形態による改善されたロック
共用ストラテジを用いたシステムにおける動作シーケン
スを示すタイミング図である。

【図４】 本発明の一実施形態に従い設計された資源共
用機構を具備したシステムを示すブロック図である。

【図５】 タイマー事象に応答して起動されたメインス
レッドによって実行されるステップを示すフローチャー
トである。

【図６】 シングルアクセス資源の使用を必要とするワ
ーカースレッドによって実行されるステップを示すフロ
ーチャートである。

【図７】 シングルアクセス資源に関連するロックを与
えられたワーカースレッドによって実行されるステップ
を示すフローチャートである。

【符号の説明】

１００ コンピュータシステム、１０１ ばす、１０２
プロセッサ、１０４主メモリ、１０７ 記憶装置、１
２１ 表示装置、１２２ キーボード、１２３ カーソ
ルコントロール。

Claims (24)

【特許請求の範囲】
1. 【請求項１】 マルチスレッド型プログラムの複数のス
   レッド間で資源を共用する方法において： （Ａ）前記複数のスレッドの中の第１のスレッドに、 （Ａ１）前記資源に関連する資源ロックを獲得するステ
   ップと； （Ａ２）その資源ロックを前記複数のスレッドの中の他
   のスレッドが前記資源の使用を要求していることを検知
   するまで保持するステップと； （Ａ３）前記複数のスレッドの中の他のスレッドの前記
   資源の使用の要求の検知に応答して、 （ａ）その資源の使用を全て終了するステップと； （ｂ）その資源ロックを解放するステップと； （ｃ）その資源ロックを要求するステップと； を実行するステップと；を実行させるステップ；を具備
   した方法。
2. 【請求項２】 上記複数のスレッドの中の上記第１のス
   レッド以外の各スレッドに、上記資源の使用を終了した
   後、上記資源ロックを第１のスレッドに対して解放させ
   るステップをさらに具備した請求項１記載の方法。
3. 【請求項３】 上記複数のスレッドの中の第２のスレッ
   ドに、その第２のスレッドが資源を使用したいというこ
   とをカウンタをインクリメントすることによって指示さ
   せるステップと；上記第１のスレッドに、複数のスレッ
   ドの中の他のスレッドがその資源の使用を必要としてい
   ることを前記カウンタを調べることによって検知させる
   ステップと；をさらに具備した請求項１記載の方法。
4. 【請求項４】 上記第２のスレッドに、上記カウンタを
   インクリメントする前にカウンタに関連するカウンタロ
   ックを獲得させるステップと；上記第２のスレッドに、
   カウンタをインクリメントした後そのカウンタに関連す
   るカウンタロックを解放させるステップと；をさらに具
   備した請求項３記載の方法。
5. 【請求項５】 タイマーを起動するステップと；そのタ
   イマーで所定の時間が経過したとき、上記第１のスレッ
   ドに、上記複数のスレッドの中の他のスレッドが上記資
   源の使用を必要としているか否かを判断させるステップ
   と；をさらに具備した請求項１記載の方法。
6. 【請求項６】 上記カウンタに関連するカウンタロック
   を獲得するステップと；上記第１のスレッドが上記資源
   ロックを解放したとき、これに応答してそのカウンタを
   デクリメントするステップと；そのカウンタに関連する
   カウンタロックを解放するステップと；をさらに具備し
   た請求項３記載の方法。
7. 【請求項７】 上記カウンタロックを獲得するステッ
   プ、上記カウンタをデクリメントするステップ、及びそ
   のカウンタロックを解放するステップが上記第１のスレ
   ッドによって実行される請求項６記載の方法。
8. 【請求項８】 上記カウンタロックを獲得するステッ
   プ、上記カウンタをデクリメントするステップ、及びそ
   のカウンタロックを解除するステップが上記第２のスレ
   ッドによって実行される請求項６記載の方法。
9. 【請求項９】 第１のキーを含むロック要求を送出する
   ことによって上記第１のスレッドに資源ロックを要求さ
   せるステップと；上記複数のスレッドの中の上記第１の
   スレッド以外の各スレッドに、第１のキーに対応する状
   態で資源ロックを解放させるステップと：をさらに具備
   した方法。
10. 【請求項１０】 上記資源がウィンドウシステムとの接
    続であり；上記資源の使用を終了するステップが上記ウ
    ィンドウシステムとの接続を全て解消するステップを含
    む；請求項１記載の装置。
11. 【請求項１１】 ある資源に関連する資源ロックを保持
    する第１のスレッドに、１つ以上の他のスレッドがその
    資源の使用を必要としていることを知らせる方法におい
    て；タイマーを起動するステップと；上記第１のスレッ
    ドを前記タイマーに基づいて周期的に起動するステップ
    と；上記第１のスレッドが上記タイマーに基づいて起動
    されたとき、その第１のスレッドに、ある記憶場所の値
    を調べることによって、他のいずれかのスレッドがその
    資源の使用を必要としているか否かを判断させるステッ
    プと；上記第１のスレッド以外のスレッドがその資源の
    使用を必要としているとき、上記第１のスレッド以外の
    スレッドに上記記憶場所の値を更新させるステップと；
    を具備した方法。
12. 【請求項１２】 上記記憶場所の値を調べた後、その値
    が他のどのスレッドも上記資源の使用を必要としていな
    いことを指示している場合に、上記第１のスレッドを中
    断状態にするステップと；上記記憶場所の値を調べた
    後、その値が他のスレッドが上記資源の使用を必要とし
    ていることを指示している場合に、上記第１のスレッド
    に上記資源ロックを解放させるステップと；をさらに具
    備した請求項１１記載の方法。
13. 【請求項１３】 上記第１のスレッドに、上記資源ロッ
    クの解放に応答して上記資源ロックを要求させるステッ
    プをさらに具備した請求項１２記載の方法。
14. 【請求項１４】 上記記憶場所の上記値が、上記第１の
    スレッド以外のいくつのスレッドが上記資源を使用する
    ために待っているかを指示し；第１のスレッドが上記資
    源ロックを解放するのに応答して、その資源を使用する
    ために待っているスレッドが１つ少なくなったことを指
    示するよう上記記憶場所のその値を更新するステップを
    さらに具備した；請求項１２記載の方法。
15. 【請求項１５】 プロセッサによって実行されたとき、
    プロセッサにマルチスレッド型プログラムの複数のスレ
    ッド間で資源をどのように共用するかを管理させる命令
    シーケンスが記憶されたコンピュータ可読媒体におい
    て、その命令シーケンスが： （Ａ）上記複数のスレッドの中の第１のスレッドに、 （Ａ１）上記資源に関連する資源ロックを獲得するステ
    ップと； （Ａ２）上記資源ロックを上記複数のスレッドの中の他
    のスレッドが上記資源の使用を要求していることを検知
    するまで保持するステップと； （Ａ３）上記複数のスレッドの中の他のスレッドが上記
    資源の使用を要求していることの検知に応答して、 （ａ）上記資源の使用を全て終了するステップと； （ｂ）上記資源ロックを解放するステップと； （ｃ）上記資源ロックを要求するステップと；を実行す
    るステップと；を実行させるための命令；をコンピュー
    タ可読媒体。
16. 【請求項１６】 上記複数のスレッドの中の上記第１の
    スレッド以外の各スレッドに、上記資源の使用を終了し
    た後、上記資源ロックを上記第１のスレッドに対して解
    放させる命令をさらに具備した請求項１５記載のコンピ
    ュータ可読媒体。
17. 【請求項１７】 上記複数のスレッドの中の第２のスレ
    ッドに、上記第２のスレッドが上記資源を使用したいと
    いうことをカウンタをインクリメントすることによって
    指示させる命令と；上記第１のスレッドに、上記複数の
    スレッドの中の他のスレッドが上記資源の使用を必要と
    していることを上記カウンタを調べることによって検知
    させるための命令と；をさらに具備した請求項１５記載
    のコンピュータ可読媒体。
18. 【請求項１８】 上記第２のスレッドに、上記カウンタ
    をインクリメントする前に上記カウンタに関連するカウ
    ンタロックを獲得させるための命令と；上記第２のスレ
    ッドに、上記カウンタをインクリメントした後上記カウ
    ンタに関連するカウンタロックを解放させる命令と；を
    さらに具備した請求項１７記載のコンピュータ可読媒
    体。
19. 【請求項１９】 タイマーを起動するための命令と；上
    記タイマー上で所定の時間が経過したとき、上記第１の
    スレッドに、上記複数のスレッドの中の他のスレッドが
    上記資源の使用を必要としているか否かを判断させるた
    めの命令と；をさらに具備した請求項１５記載のコンピ
    ュータ可読媒体。
20. 【請求項２０】 第１のキーを含むロック要求を送出す
    ることによって上記第１のスレッドに資源ロックを要求
    させる命令と；上記複数のスレッドの中の上記第１のス
    レッド以外の各スレッドに、上記第１のキーに対応する
    状態で上記資源ロックを解放させるための命令と：をさ
    らに具備した請求項１６記載のコンピュータ可読媒体。
21. 【請求項２１】 資源に関連する資源ロック、及びある
    値を記憶するメモリと；上記資源に関連する上記資源ロ
    ックを保持する第１のスレッド、及び１つ以上の他のス
    レッドを含むマルチスレッド型プログラムを実行するた
    めの少なくとも１つのプロセッサと；タイマーとを具備
    し、上記少なくとも１つのプロセッサが：上記第１のス
    レッドを上記タイマーに基づいて周期的に起動し；上記
    第１のスレッドが上記タイマーに基づいて起動されたと
    き、上記第１のスレッドに、上記値を調べることによっ
    て、他のいずれかのスレッドが上記資源の使用を必要と
    しているか否かを判断させ；上記第１のスレッド以外の
    スレッドが上記資源の使用を必要としているとき、上記
    第１のスレッド以外の上記スレッドに上記値を更新させ
    る；ことによって、上記第１のスレッドに１つ以上の他
    のスレッドが上記資源の使用を必要としていることを知
    らせるよう構成されている；コンピュータシステム。
22. 【請求項２２】 上記少なくとも１つのプロセッサが、
    さらに：上記メモリの値を調べた後、上記値が他のどの
    スレッドも上記資源の使用を必要としていないことを指
    示している場合に、上記第１のスレッドを中断状態に
    し；上記メモリの値を調べた後、上記値が他のスレッド
    が上記資源の使用を必要としていることを指示している
    場合に、上記第１のスレッドに上記資源ロックを解放さ
    せる；よう構成されている請求項２１記載のコンピュー
    タシステム。
23. 【請求項２３】 上記少なくとも１つのプロセッサが、
    さらに、上記第１のスレッドに、上記資源ロックの解放
    に応答して上記資源ロックを要求させるよう構成されて
    いる請求項２２記載のコンピュータシステム。
24. 【請求項２４】 上記値が、上記第１のスレッド以外の
    いくつのスレッドが上記資源を使用するために待ってい
    るかを指示し；上記少なくとも１つのプロセッサが、さ
    らに、上記第１のスレッドが上記資源ロックを解放する
    のに応答して、上記資源を使用するために待っているス
    レッドが１つ少なくなったことを指示するよう上記値を
    更新するよう構成されている；請求項２２記載のコンピ
    ュータシステム。