JPH1049384A

JPH1049384A - マルチスレッド環境内でオブジェクトを処分する方法および装置

Info

Publication number: JPH1049384A
Application number: JP9128409A
Authority: JP
Inventors: Christian J Callsen; クリスチャン・ジェイ・コールセン
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-05-17
Filing date: 1997-05-19
Publication date: 1998-02-20
Also published as: EP0807884A1; EP0807884B1; DE69720100D1; US6247039B1

Abstract

(57)【要約】【課題】マルチスレッド・コンピュータ環境内でスレ
ッドが安全にオブジェクトを処分する方法および装置を
提供する。【解決手段】本発明では、状態機械を各オブジェクト
と関連づける。オブジェクトの呼出しが行われたとき、
状態を削除するために状態機械に質問する。削除コール
が発生した後でオブジェクトに対して行われた呼出し
は、オブジェクトが削除されたと解釈し、そのオブジェ
クトに対するアクティブ呼出しに追加されない。さら
に、後続の削除コールもオブジェクトが削除されたと解
釈し、障害指示を戻す。初めの削除コールは、オブジェ
クトが最後に削除されたときに成功を戻す。したがっ
て、新しい呼出しは除外され、多数の削除コールが適切
に処理される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ環境
内でのオブジェクト指向プログラミングの分野に関す
る。

【０００２】

【従来の技術】従来技術のマルチスレッド・コンピュー
タ環境では、プロセスからのスレッドがオブジェクトを
削除するコールを送ると、そのスレッドは一般に、その
同じオブジェクトと相互作用する他のスレッドがクリア
するのを待つ。この待ち期間中、同じオブジェクトを呼
び出す他のスレッドが存在し、したがってそのオブジェ
クトに対するアクティブスレッドの数が減少するのでは
なく増加するのが普通である。したがって、オブジェク
トがもちろん妥当な時間内で削除されるという保証はま
ったくない。また、従来技術では、複数のスレッドがオ
ブジェクトを削除しようと試みたとき、問題が生じる。
一般に、削除するスレッドはそれぞれ、他のスレッドが
クリアされるまで待ち、したがって待っているスレッド
の数が不必要に増加する。

【０００３】オブジェクトは、業務実施など手順および
それらのデータをカプセル化する明確に定義された自蔵
ソフトウェア・モジュールである。オブジェクトは、慎
重に定義されたインタフェースを介して互いに通信する
ことによって、コンピュータを標準化された電子部品か
ら製造する方法と同様に、複雑な解決策を構成すること
ができる。再使用および標準化の多数のレベルが可能に
なり、したがってエンジニアは、高度に再使用可能かつ
レベレッジ可能なモジュール、アプリケーションおよび
システム全体を製造することができる。

【０００４】ネットワーク化オブジェクト技術では、ア
プリケーションは、実質上アプリケーションまたはオブ
ジェクトが常駐する場所と無関係に、ネットワーク内の
任意の場所においてオブジェクトおよびそれらの共用サ
ービスにアクセスすることができる。また、ネットワー
ク化オブジェクトでは、それがモデル化するアプリケー
ションまたは業務プロセスを混乱させる危険なしに個々
のオブジェクトを更新することができ、したがって複雑
なシステムの優美な漸進的発展が促進される。例えば、
新しいコンポーネントが故障した場合、そのコンポーネ
ントの先祖を迅速かつ透過的に再インストールすること
ができる。

【０００５】ネットワーク化オブジェクト環境の例は、
ネットワークおよび異なる計算プラットフォーム間でオ
ブジェクトの共用を実現するＳｕｎＳｏｆｔ^TMのＣＯＲ
ＢＡコンプライアントＮＥＯプロダクト・ファミリであ
る。

【０００６】６００以上のソフトウェア・ベンダ、開発
者、およびエンド・ユーザ組織から構成されるオブジェ
クト管理グループ（ＯＭＧ）は、異種分散オブジェクト
指向アプリケーションをサポートする共通のアーキテク
チャの基準を開発し、開発し続けている。ＯＭＧ共通オ
ブジェクト要求ブローカ・アーキテクチャ（ＣＯＲＢ
Ａ）は、多数のベンダからの異なるオブジェクト・シス
テムがネットワーク上で互いに相互作用することができ
るように設計されている。ＣＯＲＢＡ規格は、次の４つ
の構成要素を含む。ｉ）ネットワーク化環境内でオブジェクトを管理するオ
ブジェクト要求ブローカ（ＯＲＢ）ｉｉ）ＯＲＢ間通信の相互操作性ｉｉｉ）共通オブジェクト・サービス（ＣＯＲＢＡサー
ビス）ｉｖ）通常使用されるプログラミング言語のマッピング

【０００７】ネットワーク・オブジェクト要求ブローカ
（ＯＲＢ）は、標準のインタフェース・プロトコルを介
してオブジェクトのシームレス位置指定および実行を実
現し、したがってオブジェクトおよびプログラムがネッ
トワーク間で互いに透過的に相互作用することができる
ネットワーク・ベースのＣＯＲＢＡコンプライアント・
ソフトウェア・システムである。ＮＥＯＯＲＢは、必
要に応じて増減可能な性能および使用可能度を提供する
１つまたは複数のマルチスレッドＵＮＩＸプロセッサと
して実施される。

【０００８】異種オブジェクト相互操作性を促進するた
めに、ＯＭＧは、ソフトウェア・ベンダがＯＭＧコンプ
ライアント・プロダクトを試験し、送達するのを援助す
るＣＯＲＢＡ２.０インターネットＩｎｔｅｒ−ＯＲＢ
プロトコルのポータブル・ソース・コード・リファレン
ス・インプリメンテーションを提供した。インターネッ
トＩｎｔｅｒ−ＯＲＢプロトコル（Ｉｎｔｅｒｎｅｔ−
ＩＯＰ）は、異なるＣＯＲＢＡ２.０コンプライアント
・ベンダからのＯＲＢを接続し、それらが互いに通信す
ることができる標準化された方法を提供する。現在のイ
ンタフェースＩＯＰは、ＴＣＰ／ＩＰプロトコルに基づ
く。

【０００９】ＯＭＧＣＯＲＢＡサービス定義は、命
名、事象、特性、ライフ・サイクルおよび関連サービス
など、オブジェクトを用いて分散システムを作成するた
めに必要な基本的動作を規定する。

【００１０】異なるオブジェクト・システムが相互作用
する場合、言語独立性が重要である。インタフェース定
義言語（ＩＤＬ）では、インタフェースおよびインプリ
メンテーションの分離が可能であり、従ってオブジェク
ト・インプリメンテーション詳細がオブジェクトのプラ
グアンドプレイ品質を損ねることなく変更できる。ＯＭ
ＧＩＤＬは、オブジェクトの挙動をＩＤＬで定義する
ことができるオブジェクトの動作のニュートラル・イン
タフェース定義であるが、インタフェースのＣ、Ｃ＋
＋、ＯｂｊｅｃｔｉｖｅＣ、またはＳｍａｌｌｔａｌｋ
言語への自動変換に適合する。

【００１１】ＵＮＩＸによって提供されるものなど、マ
ルチスレッド環境は、一般に、ネットワーク化オブジェ
クトをサポートするのに使用される。スレッドは、より
大きいプロセスから生成され、例えば、印刷プロセスの
実施、データベース・オブジェクトに対する処置など、
いくつかの機能を実施するサブプロセスである。多数の
スレッドをサポートすることによって、システムは、多
数のクライアントおよびプロセスに同時にサービスする
ことができる。これにより、ネットワーク上でオブジェ
クトおよびサービスを共用することができる。残念なが
ら、オブジェクトが複数のスレッドによって呼び出され
た場合、オブジェクトに対して実施されるいくつかの処
置がより複雑になる。

【００１２】ＣＯＲＢＡ環境では、オブジェクト要求ブ
ローカ・デーモン・プロセス（ＯＲＢＤ）は、それに登
録されたクライアント・プロセスからオブジェクト・コ
ールを受け取る。次いで、ＯＲＢデーモンは、ネットワ
ーク上のオブジェクトを位置指定し、クライアント・プ
ロセスとネットワーク化オブジェクトの間のインタフェ
ースとして働く。ＮＥＯ環境では、ＯＲＢデーモンは、
標準のＮＥＯオブジェクトか、または場合によっては、
ＮＥＯオブジェクトとして実施すべきＮＥＯシェル内に
カプセル化されたレガシ・プロセスであるオブジェクト
用の他のインタフェースとして働くようにＮＥＯオブジ
ェクト・サーバをアクティブ化させる。ＮＥＯオブジェ
クト・サーバは、ＯＲＢデーモンによって転送されたコ
ールに応答する必要があるオブジェクトをインスタンス
化する働きをする。

【００１３】図３は、ＣＯＲＢＡコンプライアント・ネ
ットワーク・オブジェクト・システムのブロック図であ
る。多数のスレッドがエレメント３００〜３０３によっ
て示されており、スレッド３００〜３０１は、第１のク
ライアント・プロセス、クライアント・プロセス１から
生成されたスレッドであり、スレッド３０２〜３０３
は、第２のクライアント・プロセス、クライアント・プ
ロセスＮから生成されたスレッドである。図３に示すよ
うに、単一のクライアント・プロセスが任意の数のスレ
ッドを生成する。各スレッド３００〜３０３はオブジェ
クト要求ブローカ・デーモン（ＯＲＢＤ）プロセス３０
４にリンクされる。ＯＲＢＤプロセス３０４は、オブジ
ェクト・サーバ３０５およびオブジェクト・サーバ３０
７によって示される複数のオブジェクト・サーバにリン
クされる。第２のＯＲＢＤプロセス、ＯＲＢＤプロセス
３１０はさらにＯＲＢＤプロセス３０４にリンクされ
る。ＯＲＢＤ３１０は、他のオブジェクト・サーバおよ
びクライアント・プロセス（図示せず）に結合すること
もできる。オブジェクト・サーバ３０５はオブジェクト
３０６にリンクされる。オブジェクト・サーバ３０７は
オブジェクト３０８およびオブジェクト３０９にリンク
される。

【００１４】ＯＲＢＤプロセス３０４は、クライアント
・プロセス・スレッド３００〜３０３から位置指定コー
ルまたは位置指定要求の形でオブジェクト要求を受け取
り、適切なオブジェクトをサポートしているオブジェク
ト・サーバを決定する。必要なサーバが現在動作してい
ない場合、サーバがアクティブ化し、オブジェクトがイ
ンスタンス化する。オブジェクトの位置に関する情報
は、位置指定コールに応答して戻され、スレッドとオブ
ジェクトの間の他の要求は、位置情報によって指示され
る。同じオブジェクトは、オブジェクトと適用可能なす
べてのスレッドとの間の相互作用を同時に確立するため
に、他のスレッドからの位置指定コールによって同様に
呼び出される。

【００１５】ＯＲＢデーモン３１０は、インターネット
など大きいネットワークを介してネットワーク化オブジ
ェクト環境にゲートウェイを実施し、またそれ自体の定
義域内のクライアントおよびオブジェクト・サーバにプ
ラットフォーム依存インタフェースを提供すると同時
に、ＯＲＢＤ３０４に標準化されたインタフェースを提
供することによって、プラットフォーム間相互作用を実
施する。

【００１６】オブジェクト・サーバ３０５および３０７
は、オブジェクト３０６および３０８〜３０９などによ
って示されるオブジェクトまたはオブジェクト・ライブ
ラリへのアクセスを実施する。レガシ・オブジェクト、
すなわち元来ネットワーク化オブジェクト環境用に設計
されていないスタンドアロン・アプリケーションおよび
他のオブジェクトを含むオブジェクトは、オブジェクト
・サーバがそれを介してレガシ・オブジェクトの機能に
アクセスすることができるインタフェースを形成するＩ
ＤＬシェルを具備する。ネットワークが実質上ハードウ
ェア境界と無関係なとき、オブジェクトおよびオブジェ
クト・サーバはクライアント・プロセスおよびＯＲＢデ
ーモンと同じコンピュータ上に常駐するか、またはネッ
トワーク内の別々のコンピュータ上に常駐する。同様
に、ネットワーク化オブジェクト環境は実質上、ネット
ワークのベース・レベル・インプリメンテーションと無
関係である。

【００１７】上述のように、マルチスレッド環境では、
多数のスレッドが同じオブジェクトを同時に呼び出す。
これは、記憶装置を他に使用するため、またはオブジェ
クトがもはや有効でないなどのために、１つのスレッド
がオブジェクトを処分することを望むとき問題になる。
オブジェクトの処分は、サービスされるスレッドの数が
多いので、生半可なものではない。オブジェクトを突然
処分すると、サービスされている他のスレッドを混乱さ
せ、混乱およびスレッド回復のクライアント・プロセス
通知を処理する他のプロセスを要求することによってプ
ロセスが複雑になる。したがって、他のスレッドの混乱
を回避するために、オブジェクトの処分は、オブジェク
トによってサービスされているスレッドの数が０のとき
に行われるべきである。例えば、処分しようとしている
スレッドは、他のすべての現在スレッドがオブジェクト
からクリヤするのを待つ。残念ながら、その間に、同じ
オブジェクトに対してより多くのスレッド呼出しが行わ
れる。

【００１８】図１は、オブジェクト呼出しプロセスを示
す流れ図である。ステップ１００において、スレッド
は、例えば、位置指定要求によってＯＲＢデーモンから
オブジェクトのアドレスを得る。ステップ１０１におい
て、スレッドは、オブジェクトのアドレスに向けられた
メソッド呼出しによってオブジェクトを呼び出す。ステ
ップ１０２において、呼び出されているオブジェクトが
現在すでに別のスレッドによって呼び出されているかど
うかに基づいて分岐が起こる。オブジェクトが現在呼び
出されている場合、ステップ１０４において、アクティ
ブ呼出しカウントが１だけ増分される。オブジェクトが
現在別のスレッドによって呼び出されていない場合、ス
テップ１０３において、呼出しを反映するためにアクテ
ィブ呼出しカウントが初期設定される。

【００１９】ステップ１０３および１０４はステップ１
０５に到る。ステップ１０５において、オブジェクトは
要求された形でスレッドをサービスする。ステップ１０
６において、スレッドがオブジェクトによって提供され
た方法の使用を終えると、スレッドまたは呼出しが終了
し、ステップ１０７において、アクティブ呼出しの数が
１だけ増分される。オブジェクトを使用しているスレッ
ドが終了していない場合、プロセスはステップ１０５に
戻る。

【００２０】図１に示される形で、多数のスレッドが、
アクティブ呼出しカウント中に記載された連続的な呼出
しによって同じオブジェクトを呼び出す。上述のよう
に、アクティブ呼出しカウントはスレッドアクティブを
反映するが、オブジェクトは、プロセスを混乱させるこ
となく即座に処分することができない。図２は、マルチ
スレッド環境内でオブジェクトを処分する従来技術のプ
ロセスを示す。

【００２１】図２のステップ２００において、スレッド
はオブジェクトを削除するコールを送る。後続のステッ
プ２０１において、他のプロセスを混乱させることなく
処分を実施することができるかどうかを判定するため
に、そのオブジェクトに対するアクティブ呼出しの数、
すなわちオブジェクトにアクセスしているスレッドの現
在数を質問する。アクティブ呼出しの数が０であり、オ
ブジェクトにアクセスしている他のプロセス・スレッド
が存在しないことが分かった場合、ステップ２０２にお
いてオブジェクトを削除する。しかしながら、アクティ
ブ呼出しの現在数が０でない場合、まだオブジェクトを
削除できない。処分しようとしているスレッドは、ステ
ップ２０３においてアクティブ呼出しが終了するのを待
ち、アクティブ呼出しの数を質問するためにステップ２
０１に戻る。したがって、オブジェクトは、アクティブ
呼出しの数が０に達するまで削除されない。

【００２２】スレッドがオブジェクトを削除するのを待
っている間、図１に示すように、アクティブスレッドの
終了および新しいスレッドの到着を反映するために、ア
クティブ呼出しの数が更新される。ステップ２０１にお
いて最終的にアクティブ呼出しが確実に０であると判定
された場合、オブジェクトが削除される。

【００２３】オブジェクトの処分に図２のプロセスを使
用すると、削除されるオブジェクトがアクティブ呼出し
がクリヤするのを待つ間、長い遅延がもたらされる。さ
らに、新しいスレッド呼出しの可能性があるので、削除
プロセスがいつも完全であるという保証はない。その結
果、無効なオブジェクトが連続的に使用され、また削除
されないオブジェクトによって貴重な記憶装置が不必要
に占拠されることになる。

【００２４】図２のプロセスにおいて多数の削除要求を
処理するプロセスは存在しない。後続のスレッドによる
削除要求は、初めの削除コールの場合と同様に、アクテ
ィブ呼出しがクリヤするまで待っている状態に保たれ
る。これは、各場合において待っているスレッドを考慮
するためにネットワーク・オーバヘッドが増大するので
不必要であり、望ましくない。

【００２５】

【発明が解決しようとする課題】本発明は、マルチスレ
ッド・コンピュータ環境内でスレッドが安全にオブジェ
クトを処分する方法および装置を提供する。プロセスか
らのスレッドがオブジェクトを削除するコールを送る
と、そのスレッドは一般に、その同じオブジェクトと相
互作用する他のスレッドがクリアするのを待つ。この待
ち期間中、同じオブジェクトを呼び出す他のスレッドが
存在し、したがってそのオブジェクトに対するアクティ
ブスレッドの数が減少するのではなく増加するのが普通
である。また、複数のスレッドがオブジェクトを削除し
ようと試みた場合、問題が生じる。

【００２６】

【課題を解決するための手段】本発明では、状態機械を
各オブジェクトと関連づける。オブジェクトの呼出しが
行われたとき、状態を削除するために状態機械に質問す
る。削除コールが発生した後でオブジェクトに対して行
われた呼出しは、オブジェクトが削除されたと解釈し、
そのオブジェクトに対するアクティブ呼出しに追加され
ない。さらに、後続の削除コールもオブジェクトが削除
されたと解釈し、障害指示を戻す。初めの削除コール
は、オブジェクトが最終的に削除されたときに成功を戻
す。したがって、新しい呼出しは除外され、多数の削除
コールが適切に処理される。

【００２７】標準の動作中、オブジェクトの状態は「存
在する」と記録される。スレッドがオブジェクトを削除
するコールを送ると、オブジェクトは「削除すべき」状
態に入る。他のスレッドによる後続の呼出し試みは、オ
ブジェクトの状態を「削除された」と解釈し、したがっ
てこのオブジェクトのインスタンス化が阻止される。す
べてのアクティブスレッドがオブジェクトからクリヤさ
れた後、オブジェクトの状態は「削除された」に変化
し、システムはオブジェクトを処分する。

【００２８】

【発明の実施の形態】マルチスレッド環境内でオブジェ
クトを処分する方法および装置について説明する。以下
の説明では、本発明のより完全な説明を実施するために
多数の特定の詳細を詳細に記載する。しかしながら、本
発明は、これらの特定の詳細なしに実施できることが当
業者には明らかであろう。他の場合には、本発明を不必
要に曖昧にしないために、周知の特徴については詳細に
説明していない。

【００２９】本発明は、図４に示すような汎用コンピュ
ータ上で実施できる。キーボード４１０およびマウス４
１１は、双方向システム・バス４１８に結合される。キ
ーボードおよびマウスは、コンピュータ・システムにユ
ーザ入力を導入し、かつそのユーザ入力を中央演算処理
装置（ＣＰＵ）４１３に伝達するためのものである。図
４のコンピュータ・システムはまた、キーボード４１
０、マウス４１１およびＣＰＵ４１３とともにすべて双
方向システム・バス４１８に結合されたビデオ・メモリ
４１４、主メモリ４１５および大容量記憶装置４１２を
含む。大容量記憶装置４１２は、磁気、光学または磁気
光学記憶システム、あるいはその他の使用可能な任意の
大容量記憶技術など、固定媒体ならびに取外し可能媒体
を含む。バス４１８は、例えば、ビデオ・メモリ４１４
または主メモリ４１５をアドレス指定するための３２の
アドレス線を含む。システム・バス４１８はまた、例え
ば、ＣＰＵ４１３、主メモリ４１５、ビデオ・メモリ４
１４および大容量記憶装置４１２など構成要素との間お
よび構成要素間でデータを転送するための３２ビット・
データ・バスを含む。あるいは、別々のデータ線および
アドレス線の代わりに、多重データ／アドレス線を使用
することもできる。

【００３０】本発明の好ましい実施形態では、ＣＰＵ４
１３は、６８０Ｘ０プロセッサなどＭｏｔｏｒｏｌａ社
製の３２ビット・マイクロプロセッサ、または８０Ｘ８
６プロセッサやＰｅｎｔｉｕｍプロセッサなどＩｎｔｅ
ｌ社製のマイクロプロセッサである。しかしながら、他
の任意の適切なマイクロプロセッサまたはマイクロコン
ピュータも使用できる。主メモリ４１５は、ダイナミッ
ク・ランダム・アクセス・メモリ（ＤＲＡＭ）から構成
される。ビデオ・メモリ４１４は二重ポート式ビデオ・
ランダム・アクセス・メモリである。ビデオ・メモリ４
１４の１つのポートは、ビデオ増幅器４１６に結合され
る。ビデオ増幅器４１６は、陰極線管（ＣＲＴ）ラスタ
・モニタ４１７を駆動するのに使用される。ビデオ増幅
器４１６は、当技術分野において周知であり、任意の適
切な装置によって実施される。この回路は、ビデオ・メ
モリ４１４内に記憶されたピクセル・データを、モニタ
４１７が使用するのに適したラスタ信号に変換する。モ
ニタ４１７は、グラフィック・イメージを表示するのに
適したタイプのモニタである。

【００３１】ネットワーク環境内では、図４の装置は、
当技術分野において周知の適切な通信ハードウェアおよ
びソフトウェアを使用して、他の同じ装置に結合され
る。ネットワークの共用サービスにアクセスするための
フォント・エンド・システムは、Ｗｉｎｄｏｗｓ^TMを動
作させるＰＣシステム、Ｊａｖａ^TMアプリケーション・
インタフェースをサポートするウェブ・ブラウザ、Ｓｏ
ｌａｒｉｓ^TMを動作させるワークステーション、または
その組合せを含む他の適切なシステムを含む。

【００３２】上述のコンピュータ・システムは、例のた
めのものにすぎない。本発明は、任意のタイプのコンピ
ュータ・システムまたはプログラミング環境または処理
環境内で実施できる。

【００３３】従来技術では、プロセスからのスレッドが
オブジェクトを削除するコールを送ると、そのスレッド
は一般に、その同じオブジェクトと相互作用する他のス
レッドがクリアするのを待つ。この待ち期間中、同じオ
ブジェクトを呼び出す他のスレッドが存在し、したがっ
てそのオブジェクトに対するアクティブスレッドの数が
減少するのではなく増加するのが普通である。したがっ
て、オブジェクトがもちろん妥当な時間内で削除される
という保証はまったくない。また、従来技術では、複数
のスレッドがオブジェクトを削除しようと試みたとき、
問題が生じる。一般に、削除しようとしているスレッド
はそれぞれ、他のスレッドがクリアされるまで待ち、し
たがって待っているスレッドの数が不必要に増加する。

【００３４】本発明は、初めの削除要求を受け取ったと
きに、オブジェクトが最終的に削除され、かつオブジェ
クトが適時に削除されることを保証する方法および装置
を提供する。さらに、不必要に待っているスレッドがサ
ーバ待ち行列に追加されるのを防ぐために、後続の削除
要求を処理するプロセスが実施される。

【００３５】本発明では、状態機械を使用して、呼出し
を処理し、要求を削除する。オブジェクトの現在状態が
そこに記憶される状態テーブルが提供される。アクティ
ブ呼出しの現在数もそこに記憶される。要求がオブジェ
クトに送られたときはいつでも、オブジェクトの現在状
態を決定するために状態テーブルに質問する。現在状態
がどんな状態であるか、またどんなタイプの要求が行わ
れているかに応じて、要求に対する適切な応答が決定さ
れる。したがって、いくつかの状態中にいくつかのタイ
プの要求を除外するフレームワークが提供される。

【００３６】状態テーブルはプロセス内でオブジェクト
・サーバの一部として実施される。オブジェクトに割り
当てられた３状態変数は、現在状態を記憶するのに十分
であるが、状態値を記憶する他の方法も使用できる。１
つの変数が各オブジェクトに割り当てられているとき、
オブジェクトによって参照される変数のテーブル、また
は状態テーブルは、オブジェクト・サーバ内で実施さ
れ、必要に応じてオブジェクトによって質問される。オ
ブジェクトの状態変数の内容に基づいていくつかの要求
に対する応答を提供するルーチンが、オブジェクト・サ
ーバ内に用意される。

【００３７】図７は、コールにおいてターゲットにされ
たオブジェクトに対する位置指定コールおよび削除コー
ルを処理するのに適した３状態機械の一実施形態の状態
図である。オブジェクトがインスタンス化され、標準的
な形で動作しているとき、オブジェクトの状態は「存在
する」と指定される。オブジェクトのインスタンス化
は、関連するオブジェクト・サーバの開始プロセスの一
部として行われるか、またはインスタンス化は、オブジ
ェクトにおいてターゲットにされた最初の位置指定要求
に応答して行われる。いずれにせよ、オブジェクトは、
状態テーブル内に「存在する」と記録される。オブジェ
クトが削除要求を受け取り、削除されるのを待っている
とき、オブジェクトの状態は「削除すべき」と記録され
る。最後に、アクティブスレッドが存在せず、オブジェ
クトが処分されるべきであるか又は処分が済んでいる場
合、オブジェクトの状態は「削除された」と指定され
る。

【００３８】「存在する」状態で要求がスレッドから受
け取られた場合、要求はオブジェクトに転送される。削
除要求がスレッドから受け取られた場合、スレッドは待
たされ、ターゲット・オブジェクトの状態は「削除すべ
き」に進められる。

【００３９】「削除すべき」状態において、要求がスレ
ッドから受け取られた場合、ターゲット・オブジェクト
が削除されたかのように応答が発生し、それにより削除
要求が行われた後で追加の呼出しを除外する。削除要求
がこの状態において受け取られた場合、要求は戻り、障
害を指示し、それにより要求しているスレッドの不必要
な待ちを防ぎ、初めの削除要求の後の削除要求を適切に
処理する。

【００４０】アクティブ呼出し値は、オブジェクトを参
照しているスレッドの数のカウントを維持する。スレッ
ドがオブジェクトに対する要求を発生したとき、オブジ
ェクトのアクティブ呼出し値は、参照を指示するために
変化する。参照しているスレッドが存在しない場合、ア
クティブ呼出し値は０である。このアクティブ呼出し値
は、オブジェクトによって参照される第２のエントリと
して、オブジェクト・サーバ上に別々に記憶される値と
して、またはオブジェクト自体内に記憶される値とし
て、状態テーブル内に記憶される。状態は、アクティブ
呼出し値が０に達したとき「削除すべき」から「削除さ
れた」に進められる。オブジェクトに対する整理（ｃｌ
ｅａｎｕｐ）手順が初期設定され、待っているスレッド
が戻り、オブジェクトの削除が成功したことを指示す
る。

【００４１】「削除された」状態において、要求がスレ
ッドから受け取られた場合、要求は、ターゲット・オブ
ジェクトが削除されたかのように処理され、呼出しは行
われない。削除要求がスレッドから受け取られた場合、
削除要求は戻り、障害を指示する。

【００４２】上記の状態機械を実施するルーチンの一実
施形態は、ターゲット・オブジェクトの現在状態を決定
するために状態テーブルに質問することによって要求に
応答するソフトウェア・コードを含む。状態および要求
タイプに応じて、ソフトウェア・コードのある部分が障
害指示または待ち指示を戻すか、またはオブジェクトに
関する呼出しをトリガする。ターゲット・オブジェクト
の状態変数は、図７に関して指定された状態に基づいて
更新される。

【００４３】状態が「削除すべき」にセットされたと
き、ソフトウェア・コードの別の部分がターゲット・オ
ブジェクトのアクティブ呼出し値に関して「警戒（ｗａ
ｔｃｈｆｏｒ）」状態をトリガする。アクティブ呼出し
値が０に達したとき、ソフトウェア・コードはオブジェ
クト整理ルーチンをトリガし、待っているスレッドに関
して成功指示を戻す。

【００４４】上記の実施形態は１つの可能な例にすぎ
ず、また状態機械は、本発明の範囲を越えることなく他
の同様な実施形態で実施できることは明らかであろう。

【００４５】図５は、本発明の一実施形態によるオブジ
ェクトを呼び出すスレッドについてのプロセスの流れ図
である。プロセスはステップ５００から始まり、そのと
きスレッドは、ＯＲＢデーモンから、例えば位置指定要
求によってオブジェクトのアドレスを得る。ステップ５
０１において、スレッドは、オブジェクトのアドレスに
向けられたメソッド呼出しによってオブジェクトを呼び
出す。ステップ５０２において、状態機械は、現在状態
を決定するためにターゲット・オブジェクトに割り当て
られた状態変数を検査する。ステップ５０３において、
オブジェクトが「存在する」状態にない場合、すなわち
オブジェクトが「削除すべき」かまたは「削除された」
状態にある場合、ステップ５０４において、スレッドは
戻り、障害を報告する。したがって、オブジェクトが削
除されるのを待っている間、新しい呼出しは除外され
る。しかしながら、ステップ３０５において、状態変数
が、ターゲット・オブジェクトが「存在する」状態にあ
る、すなわち標準の動作中であることを反映した場合、
プロセスはステップ５０５に進む。

【００４６】ステップ５０５において、呼び出されてい
るオブジェクトが現在すでに別のスレッドによって呼び
出されているかどうかに基づいて分岐が起こる。オブジ
ェクトが現在呼び出されている場合、ステップ５０７に
おいて、アクティブ呼出しカウントが１だけ増分され
る。オブジェクトが現在別のスレッドによって呼び出さ
れていない場合、ステップ５０６において、呼出しを反
映するためにアクティブ呼出しカウントが初期設定され
る。

【００４７】ステップ５０６および５０７はステップ５
０８に到る。ステップ５０８において、オブジェクトは
要求された形でスレッドをサービスする。ステップ５０
９において、オブジェクトによって提供された方法の使
用をスレッドが終わった場合、スレッドまたは呼出しが
終了し、ステップ５１０において、アクティブ呼出しの
数が１だけ増分される。オブジェクトを使用しているス
レッドが終了していない場合、プロセスはステップ５０
８に戻る。

【００４８】図６は、本発明の一実施形態による削除要
求を送ることによってオブジェクトを削除しようと試み
るスレッドについてのプロセスの流れ図である。プロセ
スはステップ６００から始まり、そのときスレッドは、
ターゲット・オブジェクトに削除要求を送る。ステップ
６０１において、状態機械は、現在状態を決定するため
にターゲット・オブジェクトに割り当てられた状態変数
を検査する。ステップ６０２において、オブジェクトが
「存在する」状態にない場合、すなわちオブジェクトが
「削除すべき」かまたは「削除された」状態にある場
合、ステップ６０３において、スレッドは戻り、障害を
報告する。したがって、オブジェクトがすでに削除され
るのを待っている間、新しい削除要求は適切に除外され
る。しかしながら、ステップ６０２において、状態変数
が、ターゲット・オブジェクトが「存在する」状態にあ
る、すなわち標準の動作中であることを反映した場合、
プロセスはステップ６０４に進む。

【００４９】ステップ６０４において、ターゲット・オ
ブジェクトの状態変数が「削除すべき」にセットされ、
要求しているスレッドは削除プロセスが終了するのを待
つ。ステップ６０５において、アクティブ呼出し値が０
であり、アクティブ呼出しが存在しないことをが分かっ
た場合、プロセスは直接ステップ６０６に進む。しかし
ながら、アクティブ呼出し値が、アクティブ呼出しがタ
ーゲット・オブジェクトに対して残っていることを示す
０よりも大きい場合、ステップ６０９において、プロセ
スは呼出しが終了するのを待ち、その後ステップ６０５
に戻る。

【００５０】スレッドがオブジェクトを削除するのを待
っている間、図５に示すように、アクティブスレッドの
終了および新しいスレッドの到着を反映するようにアク
ティブ呼出しの数が更新される。ステップ６０５では、
一定の時間間隔をおいてアクティブ呼出しの数を検査す
るか、または各増分動作または減分動作の後でアクティ
ブ呼出しの数を検査する。ステップ６０５においてアク
ティブ呼出しが確実に０であると判定された場合、プロ
セスはステップ６０６に進む。

【００５１】すべてのアクティブスレッドがターゲット
・オブジェクトからクリアされたとき、ステップ６０６
において、状態変数が「削除された」にセットされる。
次いで、ステップ６０７において、削除要求を果たすべ
き待っているスレッドは、成功指示とともに戻る。後続
のステップにおいて、オブジェクトを削除し、関連する
メモリを再利用するために整理手順を動作させる。

【００５２】本発明では、オブジェクトが「存在する」
状態にないときにオブジェクトの追加の呼出しを防ぐこ
とによって、アクティブ呼出し値が引き続き減少し、さ
らに削除動作が適時に行われるようにする。

【００５３】また、本発明では、後続の削除要求に関す
る障害を報告することによって、不必要にスレッドが停
滞するのを防ぎ、多数の削除要求、すなわちある削除要
求の成功および他のすべての削除要求の失敗が適切に処
理されるようにする。

【００５４】以上、マルチスレッド環境内でオブジェク
トを処理する方法および装置について、１つまたは複数
の特定の実施形態に関連して説明した。本発明は、請求
の範囲およびそれらの同等物の全範囲によって規定され
る。

【図面の簡単な説明】

【図１】オブジェクトを呼び出すスレッドについての
従来技術プロセスの流れ図である。

【図２】オブジェクトを削除するスレッドについての
従来技術プロセスの流れ図である。

【図３】ＯＭＧＣＯＲＢＡ規格のもとで規定された
ものなど、ネットワーク化オブジェクト環境のブロック
図である。

【図４】本発明を実施する適切なハードウェア・シス
テムのブロック図である。

【図５】本発明の一実施形態によるオブジェクトを呼
び出すスレッドについてのプロセスの流れ図である。

【図６】本発明の一実施形態によるオブジェクトを削
除するスレッドについてのプロセスの流れ図である。

【図７】本発明の一実施形態によるオブジェクト状態
機械の図である。

【符号の説明】

３００、３０１、３０２、３０３スレッド３０４オブジェクト要求ブローカ・デーモン（ＯＲＢ
Ｄ）プロセス３０５オブジェクト・サーバ１３０６オブジェクト１／１３０７オブジェクト・サーバＮ３０８オブジェクトＮ／１３０９オブジェクトＮ／Ｎ３１０ＯＲＢデーモン２４１０キーボード４１１マウス４１２大容量記憶装置４１３中央演算処理装置（ＣＰＵ）４１４ビデオ・メモリ４１５主メモリ４１６ビデオ増幅器４１７陰極線管（ＣＲＴ）ラスタ・モニタ４１８双方向システム・バス

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成９年６月６日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【請求項１２】アクティブ呼出し数を有するオブジェ
クトと、前記オブジェクトに向けられた要求に応答する状態マシ
ンと有するマルチスレッド環境内でオブジェクトを処分
する装置。 ─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成９年７月３０日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図２】

【図１】

【図７】

【図３】

【図４】

【図５】

【図６】

Claims

【特許請求の範囲】

【請求項１】コンピュータ環境内で状態をオブジェク
トと関連づけるステップと、第１のスレッドからのオブジェクト削除要求に応答し
て、前記状態を第１の状態値から中間状態値に変更する
ステップと、アクティブ呼出しの数が０に達したときに、前記状態を
前記中間状態値から第３の状態値に変更するステップと
を含むコンピュータ環境内でオブジェクトを処分する方
法。
【請求項２】前記状態が前記第３の状態値に変化した
ときに、前記オブジェクトを削除するステップと、前記第１のスレッドを戻すステップとをさらに含む請求
項１に記載の方法。
【請求項３】前記状態が前記中間状態値を含むとき
に、第２のスレッドに、前記第２のスレッドからのオブ
ジェクト削除要求に関する障害を報告させるステップを
さらに含む請求項１に記載の方法。
【請求項４】前記状態が前記中間状態値を含んでいる
間に、前記オブジェクトの追加の呼出しを排除するステ
ップをさらに含む請求項１に記載の方法。
【請求項５】前記第１のスレッドからの要求に応答し
て前記オブジェクトを呼び出すステップと、前記第１の
スレッドによって呼び出されたときに、前記状態を前記
第１の状態値にセットするステップとをさらに含む請求
項１に記載の方法。
【請求項６】マルチスレッド環境内でオブジェクトを
処分するコンピュータ読取り可能プログラムが収納され
た記録媒体であって、コンピュータに、状態をオブジェクトと関連づけさせる
コンピュータ読取り可能プログラムと、コンピュータに、第１のスレッドからのオブジェクト削
除要求に応答して前記状態を第１の状態値から中間状態
値に変更させるコンピュータ読取り可能プログラムと、コンピュータに、アクティブ呼出しの数が０に達したと
きに、前記状態を前記中間状態値から第３の状態値に変
更させるコンピュータ読取り可能プログラムとを含むコ
ンピュータ読取り可能記録媒体。
【請求項７】コンピュータに、前記状態が前記第３の
状態値に変化したときに前記オブジェクトを削除させる
コンピュータ読取り可能プログラムと、コンピュータに、前記状態が前記第３の状態値に変化し
たときに前記第１のスレッドを戻させるコンピュータ読
取り可能プログラムとをさらに含む請求項６に記載の記
録媒体。
【請求項８】コンピュータに、前記状態が前記中間状
態値を含むときに、第２のスレッドに前記第２のスレッ
ドからのオブジェクト削除要求に関する障害を報告させ
るコンピュータ読取り可能プログラムをさらに含む請求
項６に記載の記録媒体。
【請求項９】コンピュータに、前記状態が前記中間状
態値を含んでいる間に、前記オブジェクトの追加の呼出
しを除外させるコンピュータ読取り可能プログラム・コ
ードをさらに含む請求項６に記載の記録媒体。
【請求項１０】コンピュータに、前記第１のスレッド
からの要求に応答して前記オブジェクトを呼び出させる
コンピュータ読取り可能プログラムドと、コンピュータに、前記第１のスレッドによって呼び出さ
れたときに、前記状態を前記第１の状態値にセットさせ
るコンピュータ読取り可能プログラムとをさらに含む請
求項６に記載の記録媒体。
【請求項１１】中央演算処理装置（ＣＰＵ）と、アクティブ呼出し値を有するオブジェクトと、前記オブジェクトと関連する状態変数を有する状態テー
ブルと、コードの第１の部分およびコードの第２の部分を有する
ソフトウェア・プログラム・コードを含む前記ＣＰＵに
よって実行されるプロセスとを含み、前記コードの第１の部分は、前記状態変数にアクセスす
ることによってスレッドからの要求に応答し、かつ前記
状態変数の内容に応じて前記スレッドに応答を戻し、前記コードの第２の部分は、前記アクティブ呼出し値が
０に達したときに、前記オブジェクトを処分することに
よって前記状態変数の変化に応答するマルチスレッド環
境内でオブジェクトを処分する装置。