(57)【特許請求の範囲】
【請求項１】
ノンプリエンプティブ・マルチタスク・アプリケーション・プログラムのデッドロックを回避するための方法であって、前記アプリケーション・プログラムは、ノンプリエンプティブ・マルチタスク・オペレーティング・システム中で動作し、前記アプリケーション・プログラム内の第１の構成部が、要求したリソースを、前記アプリケーション・プログラム内の第２の構成部から受け取るまで、内部的なタイムスライスに従わないとき、デッドロックが起き、
前記方法は、
(a)メイン・アプリケーション・プログラム内の他の構成部からのリソースを要求するとともに、前記メイン・アプリケーション・プログラム内の内部的なタイムスライスに従わない前記メイン・アプリケーション・プログラムの構成部を、別個のアプリケーション・プログラム中に配置するステップと、
(b)前記別個のアプリケーション・プログラムを、通信リンクを介して前記メイン・アプリケーション・プログラムに接続するステップと
を有し、
前記内部的なタイムスライスに従わない構成部は、前記他の構成部に、前記オペレーティング・システムからの制御を受けることを許可し、
前記メイン・アプリケーション・プログラムおよび前記別個のアプリケーション・プログラムは、前記オペレーティング・システムの外部的なタイムスライスに従って、プロセッサの支配権を自発的に放棄する
方法。
【請求項２】
ノンプリエンプティブ・マルチタスク・オペレーティング・システム中で動作するノンプリエンプティブ・マルチタスク・アプリケーション・プログラムのデッドロックを回避するためのシステムであって、
(a)複数個の構成部を有する第１のアプリケーション・プログラムであって、前記複数個の構成部の各々は相互にリソースを要求することがないか、または、前記複数個の構成部の各々は、相互にリソースを要求するが、前記第１のアプリケーション・プログラム内の内部的なタイムスライスに従う第１のアプリケーション・プログラムと、
(b)前記第１のアプリケーション・プログラム内の前記複数個の構成部の一つからのリソースを要求する少なくとも１個の構成部を有する第２のアプリケーション・プログラムと、
(c)前記第１のアプリケーション・プログラムと前記第２のアプリケーション・プログラムを接続する通信リンクと
を有し、
前記複数個の構成部の各々は、内部的なタイムスライスに従わないときには、他の構成部に、前記オペレーティング・システムからの制御を受けることを許可し、
前記第１のアプリケーション・プログラムと前記第２のアプリケーション・プログラムは前記通信リンクを介して互いに通信し、
前記第１のアプリケーション・プログラムおよび前記第２のアプリケーション・プログラムは、オペレーティング・システムの外部的なタイムスライスに従って、プロセッサの支配権を自発的に放棄する
システム。
【請求項３】
前記通信リンクは共有メモリおよび信号手段を含み、前記共有メモリに対してデータが伝送されたときに他方のアプリケーション・プログラムに対して信号を出すことを特徴とする、請求項２に記載のシステム。
【請求項４】
前記第１のアプリケーション・プログラムはインタフェース・スタブを含み、前記第１のアプリケーション・プログラムと前記第２のアプリケーション・プログラムの間のメッセージを受け取りまた転送することを特徴とする、請求項２に記載のシステム。
【請求項５】
前記第１のアプリケーション・プログラムおよび前記第２のアプリケーション・プログラムが前記オペレーティング・システムの前記タイムスライス動作メカニズムに従うことができるようにするための手段を有することを特徴とする、請求項２に記載のシステム。
【請求項６】
前記オペレーティング・システムがノンプリエンプティブなマルチタスク・ウインドウズ式のオペレーティング・システムであることを特徴とする、請求項２に記載のシステム。
【請求項７】
ノンプリエンプティブなマルチタスク・オペレーティング・システム中で動作するノンプリエンプティブ・マルチタスク・アプリケーション・プログラムに関連したデッドロックを回避するための方法であって、
(a)相互にリソースを要求しない構成部、または、相互にリソースを要求するが、自分が入っているアプリケーション・プログラム内の内部的なタイムスライスに従う構成部のみを含んでいる第１のアプリケーション・プログラムを、オペレーティング・システムの環境で実行するステップと、
(b)前記第１のアプリケーション・プログラム内の構成部の少なくとも一つからのリソースを要求する第２のアプリケーション・プログラムを、前記オペレーティング・システムの環境で実行するステップと、
(c)前記第１のアプリケーション・プログラムと前記第２のアプリケーション・プログラムの間で通信を行うステップと
を有し、
前記構成部の各々は、内部的なタイムスライスに従わないときには、他の構成部に、前記オペレーティング・システムからの制御を受けることを許可し、
前記第１のアプリケーション・プログラムおよび前記第２のアプリケーション・プログラムは、外部的なオペレーティング・システムのタイムスライスに従う
方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、概略的には、マルチタスク環境におけるデッドロックの回避に関するものであり、より詳細には、バックグラウンド処理を最大にし、ノンプリエンプティブなマルチタスク環境において実行されるマルチスレッド・アプリケーションにおけるデッドロックを回避するために、プロセス間通信を用いるシステムおよび方法に関するものである。
【０００２】
【従来の技術】
「ウインドウズ」環境を用いたコンピュータ・アプリケーション・プログラムは、現在の市場に普及している。ウインドウズを用いることでユーザは、マルチタスク環境下で働くことが許され、その場合、幾つかのアプリケーション・プログラムが、有限のリソースに対して競合することが可能なる。しかしながら、マルチタスク環境での動作では、多くの問題が生じる可能性がある。
【０００３】
例えば、アプリケーション・プログラムがリソースを要求して、このリソースがこの時点で利用可能ではないときには、このアプリケーション・プログラムは待機状態に入る。要求したリソースが他の待機プロセスによって保持されているため、この待機アプリケーション・プログラムが状態を再び変更しないことが起こりうる。この状況は、デッドロックと呼ばれる。デッドロックを防止するため、または、デッドロックが生じたときにそこから回復するために、システムは、一つ以上のデッドロックに陥ったアプリケーション・プログラムからのリソースの優先取得(preemption)のような、ある種の比較的先端の動作を行うことができる。
【０００４】
ある集合内の２個以上のプロセスが、この集合内の他のプロセスにのみ起こりうるイベントを待機しているとき、この集合のプロセスはデッドロック状態にある。次の４状態がシステム内で同時に保持されたとき、そして、このときにのみ、デッドロックの状況が起こりうる。
・  手動排他状態 (Manual Exclusion).  少なくとも一つのリソースが非共有モードで保持される；即ち、一時に一プロセスだけがこのリソースを使用することができる。他のプロセスがこのリソースを要求しているときには、このリソースが解放されるまで、要求プロセスは遅延されねばならない。
・  保持と待機状態 (Hold and Wait).  少なくとも一つのリソースを保持し、他のプロセスによって現在保持されているもう一つのリソースを取得するために待機する一つのプロセスが存在せねばならない。
・  優先取得不可能状態 (No Preemption).  リソースの優先取得は不可能である。即ち、リソースは、そのプロセスがタスクを完了した後に、それを保持していたプロセスによって自発的にのみ解放されることができる。
・  循環加重状態 (Circular Weight).  次のような待機プロセス集合（Ｐ0，Ｐ1，・・・，Ｐn）が存在しなければならない。すなわち、Ｐ0は、Ｐ1によって保持されているリソースを待機し，Ｐ1は、Ｐ2によって保持されているリソースを待機し，・・・，Ｐn-1は、Ｐnによって保持されているリソースを待機し，そして、Ｐnは、Ｐ0によって保持されているリソースを待機する。
【０００５】
デッドロックが起こるためには、全部で４個の条件が保持されねばならない。これらの条件の少なくとも一つが保持不可能であることを確実にすることにで、デッドロックの発生を防止することができる。デッドロック問題についてのより詳細な説明については、Peterson J. and Siberschatz A., Operating System Concepts, Addison-Wesley Publishing Co., Inc.(1986) なる文献を参照されたい。
【０００６】
ウインドウズ環境において、一つ以上の構成部からなり、プロセッサのコントロールを自発的に共有するいずれのアプリケーションも、構成部のいずれかがプロセッサのコントロールを有しているときに、他の全ての構成部が欠乏(starvation)を起こす危険がある。この状況の結果として、一般的にバックグラウンド処理の性能は貧弱なものになり、コントロールを有する構成部が他の構成部からの入力を要求するときに、デッドロックに落ち込む可能性がある。欠乏の状態にある構成部は、実行されて入力を供給することが不可能であり、コントロールを有する構成部は、この欠乏の状態にある構成部からこの入力を受け取るまでは解放されないために、デッドロックが起こる。
【０００７】
マイクロソフト（商標）・ウインドウズは、アプリケーション・プログラムを実行するためのノンプリエンプティブ(non-preemptive)なマルチタスク環境を提供する。これの意味するところは、幾つかのアプリケーションは「ふるまいが良く」、プロセッサを周期的に自発的に放棄するように準備された一連の方法で、幾つかのアプリケーションがプロセッサを共有することができるということである。例えば、マイクロソフト・ウインドウズ・オペレーティング・システムは、アプリケーション・プログラムのふるまいが良くない時には、デッドロックまたは欠乏状況の検出または補修をするためのメカニズムを備えていない。
【０００８】
【発明が解決しようとする課題】
図１は、ウインドウズ・オペレーティング・システム（ＯＳ）１１０ で実行される、幾つかのアプリケーション・プログラムの概念的な表現図である。このウインドウズ・オペレーティング・システムは、マルチタスクのオペレーティング・システムである。マルチタスクとは、一つ以上のアプリケーション・プログラムを同時に走らせることを意味する。ノンプリエンプティブとは、アプリケーション・プログラムが、例えば、アプリケーション・プログラム Ａ １２０ が、ウインドウズ・オペレーティング・システム １１０ によって、プロセッサ（図示せず）へのアクセスを許容されたときには、アプリケーション・プログラムＢ １３０，Ｃ １４０ または Ｄ １５０ による優先取得はできないということを意味する。かくして、アプリケーション・プログラム Ａ １２０ が実行されているときには、他の全てのアプリケーション・プログラム １３０，１４０，１５０ は欠乏状態にされる。受け入れたウインドウズ・プログラムの実行により、アプリケーション・プログラム １２０ないし１５０ は、プロセッサに対するアクセスを自発的に放棄するように命令される（即ち、アプリケーション・プログラムはふるまいを良くする）。かくして、各々のアプリケーション・プログラムは、プロセッサの時間のタイムスライスを受け取る。タイムスライスは、オペレーティング・システムがアプリケーション・プログラムの実行を許す時間の単位である。ノンプリエンプティブなシステムでは、タイムスライスは予め定義された制限を持たない。
【０００９】
アプリケーション・プログラム １２０ないし１５０ の一つがプロセッサのコントロールを一旦解放すると、ウインドウズ・オペレーティング・システム １１０ は、他のアプリケーション・プログラム １２０ないし１５０ の一つがプロセッサに対してアクセスすることを許可する（スケジュール化する）ことができる。
【００１０】
ある種のアプリケーション・プログラムにおいては、このアプリケーション・プログラム内での分割したタスクまたはスレッドを介して、それら自身の内部的なノンプリエンプティブなマルチタスクを提供している。アプリケーション・プログラム内でマルチタスクを行うもの(multi-tasker)は、ウインドウズ・オペレーティング・システム １１０内で見出されるマルチタスクを行うものと同様なものであることに注意されたい。例えば、あるスレッドはディスク上でのデータをアクセスするためのものであり、一方、別のスレッドはテープからのデータをアクセスするためのものであり、また、別のスレッドはユーザと対話して実行すべき動作を決定するものである。データは「バックグラウンド」処理を介して即座に利用可能にされるため、本設計の目標は、ユーザの要求に対して、より迅速な応答を発することにある。
【００１１】
スレッドはそのタイムスライスの間にプロセッサのコントロールを有し、メッセージの通過を介して、他のスレッドと通信する。このスレッド間のタイムスライス、および、スレッド間のメッセージの通過は、一つのウインドウズ・オペレーティング・システム １１０ のタイムスライスの間に、アプリケーション・プログラム １２０ないし１５０ の一つ内で起こるものである。
【００１２】
ウインドウズ・オペレーティング・システム １１０ によれば、ユーザと通信する方法を標準化するインタフェースが、アプリケーション・プログラム １２０ないし１５０ に付与される。例えば、ダイアログ・ボックス，リスト・ボックス，スクロール・バー，エディット・コントロール，カーソル，アイコン等が付与される。アプリケーション・プログラムのユーザ・インタフェース・スレッドは、ユーザから異なるタイプの情報を得るためにダイアログ・ボックスを使用する。ダイアログ・ボックスは、ウインドウズ・アプリケーション・インタフェースによって提供され、それ自体のウインドウズ・メッセージ・ループを備える。アプリケーション・プログラム １２０ないし１５０ の一つによって提示されたダイアログ・ボックスはふるまいが良いものであり、また、ウインドウズ・ソフトウエア １１０ に従って、他のアプリケーション・プログラム １２０ないし１５０ が実行されることを許容する。しかしながら、アプリケーション・プログラムのダイアログ・ボックス内のメッセージ・ループは、この特定のアプリケーション・プログラムに対する全てのウインドウズ・ソフトウエア １１０ メッセージを受け取る。かくして、アプリケーション・プログラムのユーザ・インタフェース・スレッドが、スクリーン上にダイアログ・ボックスを配置するならば、このダイアログ・ボックスはこのアプリケーション・プログラムの全てのメッセージを受け取り、また、このアプリケーション・プログラム内の他のスレッドは、このダイアログ・ボックスが除去されるまでは、実行されない。これにより、アプリケーション・プログラム内の他のスレッドは、欠乏状態に導かれる。ダイアログ・ボックスがコントロールを有している間、アプリケーション・プログラム内の他のスレッドによるバックグラウンド処理操作は行われず、これによってデッドロックに導くことができる。
【００１３】
例えば、テープ・ディレクトリの内容を印刷することをユーザが希望すると、ユーザ・マネージャ・スレッドは、ダイアログ・ボックスにユーザが印刷するものを選択するのを許し、印刷処理をコントロールすることを許す。一旦、ユーザが印刷すべきディレクトリを選択すると、ユーザ・マネージャ・スレッドは、テープ・マネージャ・スレッドに、ディレクトリ内の各アイテムに対する要求を伝送する。このテープ・マネージャ・スレッドは、次に、印刷されるべき各ファイルの名前を戻す。ダイアログ・ボックスの性質のため、アプリケーション・プログラム内の他のスレッドは、このダイアログ・ボックスが取り除かれるまで実行されることはない。故に、テープ・マネージャ・スレッドは、タイムスライスを受け取らない。タイムスライスなしでは、テープ・マネージャ・スレッドは、（テープからファイルのリストを読み取るような）いかなるバックグラウンド処理も実行することができない。ダイアログ・ボックスはそのジョブを完了するためにテープ・マネージャ・スレッドからの情報を要求し、また、ダイアログ・ボックスがアプリケーションのコントロールを有しているためにこのテープ・マネージャ・スレッドは実行できないことから、デッドロックが起こる。
【００１４】
以上のように、必要とされるのは、ノンプリエンプティブでマルチタスクなオペレーティング・システムにおいて実行される、ノンプリエンプティブでマルチタスクなアプリケーション・プログラムにおけるデッドロックを回避するためのシステムおよび方法である。
【００１５】
【課題を解決するための手段】
本発明は、ノンプリエンプティブの態様で、それ自体がマルチタスクなアプリケーション・プログラムにおいてデッドロックを回避するシステムおよび方法を提供する。このアプリケーション・プログラムは、それ自体もノンプリエンプティブなマルチタスク環境を提供するオペレーティング・システムにおいて動作する。必要とする全てのリソースが一致するまでは、内部的なタイムスライス操作に従わないアプリケーション・プログラムの全ての構成部は、個別の実行形式（即ち、個別のアプリケーション・プログラム）に分離されねばならない。構成部を個別の実行形式に分離することにより、バックグラウンド処理の性能を最大にし、デッドロックを回避することが可能になる。これらの構成部に対する内部的なタイムスライス操作は、アプリケーション・プログラム内の全ての他の構成部がそれらの作業の割当を実施することができる機会を確実に持てるような、外部的なオペレーティング・システムのタイムスライス操作によって置き換えられる。
【００１６】
とくに、プロトコルが実行形式の通信のために定義されるため、一つの実行形式が直接的又は間接的に他の実行形式の機能を実行することはない。内部的なタイムスライス操作に対する解放をしない構成部は、固有の実行形式内に配置される。全ての他の構成部および違反している構成部のスタブは、他の実行形式（メインの実行形式）内に配置される。次に、２個の実行形式間の通信リンクが設定される。違反している構成部が実行されることがメインの実行形式によって判定される度に、この違反している構成部のスタブが呼ばれる。このスタブは、メインの実行形式と、現在ではそれと分離した実行形式内にある違反した構成部との間のメッセージの送受をするものである。
【００１７】
違反している構成部およびシステムの残部はオペレーティング・システムによってマルチタスク操作されることから、このオペレーティング・システムがメインの実行形式に周期的に実行する許可を与えるため、デッドロックが回避される。このメインの実行形式は、違反している構成部によって要求された入力の発生および伝達を行い、この違反している構成部のリソースの要求を満足させることができる。
【００１８】
【実施例】
図２には、ノンプリエンプティブなマルチタスク・アプリケーション・プログラム ２００ の例が示されている。このアプリケーション・プログラム ２００ に含まれているものは、タスク・マネージャ ２１０，ユーザ・インタフェース・マネージャ・スレッド ２２０，リスト・マネージャ・スレッド ２３０，テープ・マネージャ・スレッド ２４０，および、デバイス・ドライバー・マネージャ・スレッド ２５０ である。これらは単に例示的なスレッドであり、必要に応じて他のスレッドの代替または追加が可能であることに注意されたい。
【００１９】
図３には、ノンプリエンプティブなマルチタスク・アプリケーション・プログラム ２００ の、より詳細な図が示されている。アプリケーション・プログラム２００ が一旦ウインドウズ・オペレーティング・システム １１０ から実行の許可を得ると、アプリケーション・プログラム ２００ 内のタスク・マネージャ２１０ が制御をする。タスク・マネージャ ２１０ は、ユーザ・インタフェース・スレッド ２２０ に対して実行を許可する。ユーザ・インタフェース・スレッド ２２０ はダイアログ・ボックス ３１０ を提示する。ダイアログ・ボックス ３１０ は他のタスク ２３０，２４０，および ２５０ からのサービスを要求する。ユーザ・インタフェース・スレッド ２２０ は（ダイアログ・ボックス３１０ を介して），このダイアログ・ボックス ３１０ を取り除く前に他のタスクからの応答を待機する。しかしながら、タスク・マネージャ ２１０ はユーザ・インタフェース・スレッド ２２０ がそのタイムスライスを放棄するのを待機しているため、このタスク・マネージャ ２１０ を実行する許可を与えないので、他のタスクが応答することはない。ダイアログ・ボックス ３１０ は、その要求に対する応答を受け取るまでは取り除かれることがないため、ユーザ・インタフェース・スレッド ２２０ がそのタイムスライスを放棄することはない。その結果はデッドロックである。
【００２０】
図３に示されているように、ユーザ・インタフェース・スレッド ２２０ は、リンク ３３０（および関連のメッセージ・ループ ３５０）を介して、ウインドウズのタイムスライスのメカニズムに自発的に従う。しかしながら、リンク ３４０（および関連のメッセージ・ループ ３２０）を介して、そのタイムスライスを放棄することはない。このリンク ３４０（および関連のメッセージ・ループ ３２０）は、タスク・マネージャ ２１０ が内部的なタイムスライスのスケジュール化の制御を回復することを許可する。
【００２１】
換言すれば、アプリケーションはノンプリエンプティブで、また、現在実行中の構成部を有していることから、このアプリケーションのタスク・マネージャが現に実行中の構成部からの制御の戻りを受け取るまでは、このアプリケーションの他の構成部が開始されることは不可能である。いずれかの他の構成部からの入力を受け取るまでは、この構成部が実行を停止することがないために、アプリケーション・プログラム ２００ はデッドロック状態になる。
【００２２】
リソースの競合に対する一般的な解決策は、単一の構成部でのリソースに対する要求を分離することである。他のスレッドからの情報がリソースとして考えられるときには、ユーザ・インタフェース・スレッドにおけるダイアログ・ボックス ３１０ は、一時に幾つかのリソース（例えば、他のスレッドからのプロセッサおよび情報）を要求することができる。
【００２３】
デッドロックの問題を解決するために、違反している構成部は、この場合におけるユーザ・インタフェース・スレッド ２２０ は、一つの分離した実行形式（即ち、一つの分離したアプリケーション・プログラム）に配置されねばならず、違反している構成部が内部的なタイムスライス操作のメカニズムに従わないときには、（全ての他のスレッドを含む）システムの残部は、ウインドウズ・オペレーティング・システム １１０ からの制御を受け取ることを許可する。この解決策によるアプリケーション・プログラム ２００ は２個の分離した実行形式を備え、それぞれにオペレーティング・システム（ウインドウズ）のタイムスライスを受け取り、単一のアプリケーション・プログラム内の欠乏およびデッドロックに対する可能性を軽減する。しかしながら、この解決策によるときには、２個の実行形式の間で情報を送るために、プロセス間通信の方法が必要とされる。
【００２４】
ダイアログ・ボックスで誘発される欠乏（および、ウインドウズ・オペレーティング・システムにおけるデッドロックの問題）は、ダイアログ・ボックスがウインドウズ・オペレーティング・システム １１０ に従い、他のアプリケーション・プログラムが実行されることを許可する、ということを認識することによって回避することができる。図４を参照すると、アプリケーション・プログラム ２００ は次の２個の部分に分離されている。即ち、（１）ユーザ・インタフェース・スレッド ２２０ からなるユーザ・インタフェース実行形式、および、（２）他の全てのスレッドからなるシステムの残部に分断され、他のスレッドの潜在的な欠乏を除外している。システムの残部が規則的な外部のウインドウズ・タイムスライスを受け取ることを許可するために、ユーザ・インタフェース・スレッド ２２０ はもはや内部的なタイムスライス操作のメカニズムに従うことを要求されない。従って、ダイアログ・ボックスが存在するときでも、バックグラウンド処理を生起させることができる。
【００２５】
好適実施例においては、プロセス間通信（即ち、アプリケーション・プログラム間の）通信は、マイクロソフトのウインドウズ ３．ｘ オペレーティング・システムによって提供されるウインドウズ・ダイナミック・データ・エクスチェンジ（ＤＤＥ）プロトコルを用いて達成される。ＤＤＥ プロトコルは、２個の実行形式間での通信をするために用いられる。ＤＤＥ プロトコルは、また、ある一つのアプリケーション・プログラムに対し、データを共有メモリ位置内に配置させ、次に、他のアプリケーション・プログラムに対してこのデータが利用可能である旨を知らせることを可能にする。ＤＤＥ プロトコルについてのより詳細な説明のためには、Microsoft Windows 3.1 Guide to Programming, programmers reference library, Microsoft Press, Chapter 22, 1987-1992 を参照されたい。
【００２６】
図４には、本発明が例示されている。即ち、ユーザ・インタフェース・スレッド ２２０ は、それ自身のアプリケーション・プログラム ４１０ 内に配置されている。全ての他のスレッド ２１０，２３０ないし２５０ は、それらに固有のアプリケーション・プログラム ４２０ 内に配置されている。ＤＤＥ リンク ４３０ は、２個のアプリケーション・プログラム ４１０ および ４２０ を接続させている。アプリケーション・プログラム ４２０ には、更に、ユーザ・インタフェース・スタブ ４４０ が含まれている。このユーザ・インタフェース・スタブは、アプリケーション・プログラム ４２０ に対するユーザ・インタフェース・スレッド ２２０ に「類似した」ソフトウエアの一部分であるが、現在では分離しているアプリケーション・プログラム ４１０ とタスク・マネージャ ２１０ との間のメッセージの送受に携わる働きをするだけである。
【００２７】
先のデッドロックを誘発するシナリオは次のように作用する。ユーザは、テープ上のディレクトリの内容を印刷することを希望する。分離しているユーザ・インタフェース・アプリケーション ４１０ はダイアログ・ボックスを提示して、ユーザが印刷するものを選択することを許し、印刷操作を制御することを許可する。ユーザが印刷すべきディレクトリを一旦選択すると、ダイアログ・ボックスは、ＤＤＥ プロトコルおよび通信リンク ４３０ を用いて、システムの分離したアプリケーション・プログラム ４２０ の残部におけるテープ・マネージャ・スレッド ２４０ へディレクトリ内の各アイテムに対する要求を送る。ダイアログ・ボックス ３１０ はウインドウズ・オペレーティング・システム １１０ に従い、システムのアプリケーション・プログラムの残部はこのウインドウズ・オペレーティング・システム １１０ からの制御を得る。テープ・マネージャ・スレッド ２４０ はユーザ・マネージャ・スタブ ４４０ からのメッセージを受け取り、印刷されるべきファイルの名前を返す。
【００２８】
システムのアプリケーション・プログラムの残部は最終的にウインドウズ・オペレーティング・システム １１０ に従い、ユーザ・インタフェース・アプリケーション ４１０ は最終的にウインドウズ・オペレーティング・システム １１０ からの制御を回復する。ユーザ・インタフェース・アプリケーション ４１０は ＤＤＥ リンク ４３０ を介してテープ・マネージャからのメッセージを読み、印刷されるべきファイルの名前をプリンタ（図示せず）に送る。全ての要求されたファイルの名前が印刷されるまでこのサイクルが繰り返される。デッドロックは回避される。
【００２９】
デッドロックに係わる問題はウインドウズの環境に固有のものではない。このようなものとして、本発明はウインドウズに基づくアプリケーションに限定されるべきものではない。例えば、ノンプリエンプティブでマルチタスクの態様で動作するいかなるオペレーティング・システム環境でも、本発明についての教示から利益を得ることができる。
【００３０】
本発明は、それ自体に好適な実施例を参照して詳細に図示され、説明されたものであるが、当業者には理解されるように、本発明の精神および範囲から逸脱することなく、形式および詳細における種々の変更をその中で施すことができる。
【００３２】
【発明の効果】
以上のように、本発明を用いると、ノンプリエンプティブでマルチタスクなオペレーティング・システムにおいて実行される、ノンプリエンプティブでマルチタスクなアプリケーション・プログラムにおけるデッドロックを回避するためのシステムおよび方法が提供される。
【図面の簡単な説明】
【図１】ウインドウズ・オペレーティング・システムのためのマルチタスク環境のハイ・レベルな表現図である。
【図２】単一のアプリケーション・プログラムにおける、ノンプリエンプティブなマルチタスク操作の例示図である。
【図３】ウインドウズ・オペレーティング・システムに結合されている、図２に示されたノンプリエンプティブなマルチタスク・アプリケーション・プログラムの例示図である。
【図４】ノンプリエンプティブな方法でそれ自身マルチタスク動作するアプリケーション・プログラムに関連したデッドロックの問題に対する解決策の例示図である。
【符号の説明】
１１０：ウインドウズ・オペレーティング・システム
１２０：アプリケーション・プログラム  Ａ
１３０：アプリケーション・プログラム  Ｂ
１４０：アプリケーション・プログラム  Ｃ
１５０：アプリケーション・プログラム  Ｄ
２００：アプリケーション・プログラム
２１０：タスク・マネージャ
２２０：ユーザ・インタフェース・マネージャ・スレッド
２３０：リスト・マネージャ・スレッド
２４０：テープ・マネージャ・スレッド
２５０：デバイス・ドライバー・マネージャ・スレッド
３１０：ダイアログ・ボックス
３２０，３５０：メッセージ・ループ
３３０，３４０：リンク
４１０，４２０：アプリケーション・プログラム
４３０：ＤＤＥ リンク
４４０：ユーザ・インタフェース・スタブ
【図１】
0003717951.tif 000002
【図２】
0003717951.tif 000003
【図３】
0003717951.tif 000004
【図４】
0003717951.tif 000005