JPH08123700A - 資源管理方法 - Google Patents
資源管理方法Info
- Publication number
- JPH08123700A JPH08123700A JP25540394A JP25540394A JPH08123700A JP H08123700 A JPH08123700 A JP H08123700A JP 25540394 A JP25540394 A JP 25540394A JP 25540394 A JP25540394 A JP 25540394A JP H08123700 A JPH08123700 A JP H08123700A
- Authority
- JP
- Japan
- Prior art keywords
- thread
- program area
- task
- program
- space
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Abstract
(57)【要約】
【目的】 資源管理方法において、スレッド終了時とス
レッド再生時の実行性能及び、動的なプログラム域の回
収要求時とプログラム域の再獲得要求時の実行性能を向
上させる。 【構成】 空間内に１又は複数のタスクを有し、タスク
内に１又は複数のスレッドを有し、タスク単位でファイ
ル管理制御表を用いてファイル管理を行い、スレッド単
位でプログラム域管理制御表を用いてプログラム管理を
行う資源管理方法において、スレッド終了時には、プロ
グラム域とそのスレッドに持つシステム資源のみを回収
する。また、動的なプログラム回収要求時には、プログ
ラム域のみを回収する。プログラム域の獲得時又はスレ
ッド再生時の実行性能を向上させることが可能となる。
レッド再生時の実行性能及び、動的なプログラム域の回
収要求時とプログラム域の再獲得要求時の実行性能を向
上させる。 【構成】 空間内に１又は複数のタスクを有し、タスク
内に１又は複数のスレッドを有し、タスク単位でファイ
ル管理制御表を用いてファイル管理を行い、スレッド単
位でプログラム域管理制御表を用いてプログラム管理を
行う資源管理方法において、スレッド終了時には、プロ
グラム域とそのスレッドに持つシステム資源のみを回収
する。また、動的なプログラム回収要求時には、プログ
ラム域のみを回収する。プログラム域の獲得時又はスレ
ッド再生時の実行性能を向上させることが可能となる。
Description
【０００１】
【産業上の利用分野】本発明は、コンピュータの資源管
理に関するものである。 〔技術の背景〕始めに、プログラムの実行体について図
３を用いて説明する。図に示すように、プログラムの実
行体は、空間１、タスク２、スレッド３から構成され
る。
理に関するものである。 〔技術の背景〕始めに、プログラムの実行体について図
３を用いて説明する。図に示すように、プログラムの実
行体は、空間１、タスク２、スレッド３から構成され
る。
【０００２】空間１は、システムコールなどの定められ
たインタフェースに基づいて、空間外から制御可能な唯
一の単位である。空間１は、それぞれが１つの独立した
アドレス空間で構成され、空間１の内部では、内部実行
体であるタスク２及びスレッド３が動作してプログラム
を実行する。空間間では、インタフェースを介さずに互
いに影響を及ぼすことはできない。したがって、セキュ
リティの上で、最も強固な実行環境である。
たインタフェースに基づいて、空間外から制御可能な唯
一の単位である。空間１は、それぞれが１つの独立した
アドレス空間で構成され、空間１の内部では、内部実行
体であるタスク２及びスレッド３が動作してプログラム
を実行する。空間間では、インタフェースを介さずに互
いに影響を及ぼすことはできない。したがって、セキュ
リティの上で、最も強固な実行環境である。
【０００３】タスク２は、空間１内に１つの独立したプ
ログラム実効環境（例えば、Ｃ言語では main 関数を持
つプログラムの実行環境）を提供する。空間１内では、
複数のタスク２が存在してプログラムを多重に実行する
ことが可能である。タスク２は、特に、通信アプリケー
ションプログラムの実行環境を構築する際に有効なもの
である。タスクの独立性の高いプログラム実行環境によ
り、１つの空間内でアプリケーションプログラムを多重
に実行することができるため、空間資源の削減がはかれ
る。
ログラム実効環境（例えば、Ｃ言語では main 関数を持
つプログラムの実行環境）を提供する。空間１内では、
複数のタスク２が存在してプログラムを多重に実行する
ことが可能である。タスク２は、特に、通信アプリケー
ションプログラムの実行環境を構築する際に有効なもの
である。タスクの独立性の高いプログラム実行環境によ
り、１つの空間内でアプリケーションプログラムを多重
に実行することができるため、空間資源の削減がはかれ
る。
【０００４】スレッド３は、ＣＰＵの実行権を得てプロ
グラムの命令列を実行する最も基本的な制御単位であ
る。個々のタスク２は、その内部に複数のスレッド３を
以てプログラムを並列処理することが可能である。各ス
レッド３には、スレッドの持つ実行優先度にしたがっ
て、ＣＰＵの実行権が時分割で分配される。スレッドが
ＣＰＵの実行権を得ると、そのスレッドに結び付けられ
たプログラムの命令コードが実行される。実行スレッド
の切り換えに際しては、切り換え前の実行環境は退避さ
れ、再実行時には退避された実行環境が復元される。
グラムの命令列を実行する最も基本的な制御単位であ
る。個々のタスク２は、その内部に複数のスレッド３を
以てプログラムを並列処理することが可能である。各ス
レッド３には、スレッドの持つ実行優先度にしたがっ
て、ＣＰＵの実行権が時分割で分配される。スレッドが
ＣＰＵの実行権を得ると、そのスレッドに結び付けられ
たプログラムの命令コードが実行される。実行スレッド
の切り換えに際しては、切り換え前の実行環境は退避さ
れ、再実行時には退避された実行環境が復元される。
【０００５】スレッド３は、特にＧＳ（ＯＳのサーバ）
の並列処理を実現する際に有効である。ＧＳでは、クラ
イアントからの処理要求を高速に処理するために、個々
のスレッドが、クライアントからのそれぞれの処理要求
を処理するように使用される。以上のようなプログラム
実行体の構造化により、元々プログラム実行体が合わせ
持っていた諸資源、諸属性は、空間資源４、タスク資源
５、スレッド資源６に分解されている（これらの資源に
ついては後述する。）。
の並列処理を実現する際に有効である。ＧＳでは、クラ
イアントからの処理要求を高速に処理するために、個々
のスレッドが、クライアントからのそれぞれの処理要求
を処理するように使用される。以上のようなプログラム
実行体の構造化により、元々プログラム実行体が合わせ
持っていた諸資源、諸属性は、空間資源４、タスク資源
５、スレッド資源６に分解されている（これらの資源に
ついては後述する。）。
【０００６】このようなプログラム実行体の構造化によ
り、プログラムの用途ごとに最適な実行環境と実行形態
を実現している。ここで、空間資源４、タスク資源５、
スレッド資源６について説明をする。空間１は、空間内
の全タスク２により共用される空間資源４を持つ、この
ような資源には、システム内で空間を一意に識別するプ
ロセスｉｄ、空間の権限を示す利用者ｉｄ、グループｉ
ｄなどがある。これらの空間資源４は、そもそも空間固
有の性質を持ち、下位の実行体（タスク２又はスレッド
３）に割りつけられ得ない資源、プログラムによって変
更される可能性が少なくタスク２による共有に問題のな
い資源等である。（逆に、空間１が複数タスク２を持っ
て動作する場合には、各タスク内で動作するプログラム
は、他のタスクに影響を及ぼすような空間資源の変更を
制限される。） 以下は、代表的な空間資源４の一覧である。 １．プロセスｉｄ ２．親プロセスｉｄ ３．プロセスグループｉｄ ４．セション ５．実利用者ｉｄ、実グループｉｄ、実効利用者ｉｄ、
実効グループｉｄ、退避利用者ｉｄ、退避グループｉｄ ６．カレントワーキングディレクトリ ７．ルートディレクトリ ８．ファイルモード生成マスク ９．外部変数environ から指される環境変数 １０．ロードモジュールライブラリ １１．事前オープンファイル ただし、環境変数については、タスクが自身の外部変数
environ の値を変更し、タスク固有の環境変数域を指す
ように変更することができる。
り、プログラムの用途ごとに最適な実行環境と実行形態
を実現している。ここで、空間資源４、タスク資源５、
スレッド資源６について説明をする。空間１は、空間内
の全タスク２により共用される空間資源４を持つ、この
ような資源には、システム内で空間を一意に識別するプ
ロセスｉｄ、空間の権限を示す利用者ｉｄ、グループｉ
ｄなどがある。これらの空間資源４は、そもそも空間固
有の性質を持ち、下位の実行体（タスク２又はスレッド
３）に割りつけられ得ない資源、プログラムによって変
更される可能性が少なくタスク２による共有に問題のな
い資源等である。（逆に、空間１が複数タスク２を持っ
て動作する場合には、各タスク内で動作するプログラム
は、他のタスクに影響を及ぼすような空間資源の変更を
制限される。） 以下は、代表的な空間資源４の一覧である。 １．プロセスｉｄ ２．親プロセスｉｄ ３．プロセスグループｉｄ ４．セション ５．実利用者ｉｄ、実グループｉｄ、実効利用者ｉｄ、
実効グループｉｄ、退避利用者ｉｄ、退避グループｉｄ ６．カレントワーキングディレクトリ ７．ルートディレクトリ ８．ファイルモード生成マスク ９．外部変数environ から指される環境変数 １０．ロードモジュールライブラリ １１．事前オープンファイル ただし、環境変数については、タスクが自身の外部変数
environ の値を変更し、タスク固有の環境変数域を指す
ように変更することができる。
【０００７】個々のタスク２は、それぞれがプログラム
が使用する外部変数やファイルのオープン環境などのタ
スク資源を持ち、他タスクとの資源の競合を起こさない
プログラム実行環境を提供する。以下は、代表的なタス
ク資源５の一覧である。 １．タスクｉｄ ２．プログラムの外部変数域 ３．ファイルディスクリプタ、Ｉ／Ｏバッファ ４．動的獲得領域 スレッド３は、以下の代表的なスレッド資源だけを持
ち、軽量な実行制御の体を実現している。 １．スレッドｉｄ ２．ＰＳＷや汎用レジスタなどのＣＰＵ資源 ３．プログラムの静的局所変数域 ４．シクナルのマスタとシグナルの応答動作
が使用する外部変数やファイルのオープン環境などのタ
スク資源を持ち、他タスクとの資源の競合を起こさない
プログラム実行環境を提供する。以下は、代表的なタス
ク資源５の一覧である。 １．タスクｉｄ ２．プログラムの外部変数域 ３．ファイルディスクリプタ、Ｉ／Ｏバッファ ４．動的獲得領域 スレッド３は、以下の代表的なスレッド資源だけを持
ち、軽量な実行制御の体を実現している。 １．スレッドｉｄ ２．ＰＳＷや汎用レジスタなどのＣＰＵ資源 ３．プログラムの静的局所変数域 ４．シクナルのマスタとシグナルの応答動作
【０００８】
【従来の技術】従来の資源管理方法においては、プログ
ラム域とこれを管理するシステム資源を一体と考え、プ
ログラム域を回収するときは、システム資源も回収の対
象としていた。ところが、技術の進展に伴い、プログラ
ム域が日々増加しているため、これを管理するシステム
資源も当然増加してきている。
ラム域とこれを管理するシステム資源を一体と考え、プ
ログラム域を回収するときは、システム資源も回収の対
象としていた。ところが、技術の進展に伴い、プログラ
ム域が日々増加しているため、これを管理するシステム
資源も当然増加してきている。
【０００９】
【発明が解決しようとする課題】このような状況にあっ
ては、シングルタスクが動作する環境においては、スレ
ッドの終了が空間の終了と同一であるため、わざわざス
レッドやタスクで管理している資源を回収する必要はな
いので、実行性能を悪化させることはない。しかしなが
ら、マルチタスクが動作する環境においては、スレッド
の終了が空間まで終了するわけではないので、陽に資源
を回収する必要がある。したがって、マルチタスクにお
いては、回収すべきプログラム域又はこれを管理するシ
ステム資源が増加すると、実行性能を著しく悪化させて
しまう。
ては、シングルタスクが動作する環境においては、スレ
ッドの終了が空間の終了と同一であるため、わざわざス
レッドやタスクで管理している資源を回収する必要はな
いので、実行性能を悪化させることはない。しかしなが
ら、マルチタスクが動作する環境においては、スレッド
の終了が空間まで終了するわけではないので、陽に資源
を回収する必要がある。したがって、マルチタスクにお
いては、回収すべきプログラム域又はこれを管理するシ
ステム資源が増加すると、実行性能を著しく悪化させて
しまう。
【００１０】本発明は、資源管理方法において、スレッ
ド終了時とスレッド再生時の実行性能を向上させること
を目的とする。更に、本発明は、動的なプログラム域の
回収要求時とプログラム域の再獲得要求時の実行性能を
向上させることを目的とする。
ド終了時とスレッド再生時の実行性能を向上させること
を目的とする。更に、本発明は、動的なプログラム域の
回収要求時とプログラム域の再獲得要求時の実行性能を
向上させることを目的とする。
【００１１】
【課題を解決するための手段】本発明は、上記第１の目
的を達成するため、空間内に１又は複数のタスクを有
し、前記タスク内に１又は複数のスレッドを有し、前記
タスク単位でファイル管理制御表を用いてファイル管理
を行い、前記スレッド単位でプログラム域管理制御表を
用いてプログラム管理を行う資源管理方法において、ス
レッド終了時には、プログラム域とそのスレッドに持つ
システム資源のみを回収する。
的を達成するため、空間内に１又は複数のタスクを有
し、前記タスク内に１又は複数のスレッドを有し、前記
タスク単位でファイル管理制御表を用いてファイル管理
を行い、前記スレッド単位でプログラム域管理制御表を
用いてプログラム管理を行う資源管理方法において、ス
レッド終了時には、プログラム域とそのスレッドに持つ
システム資源のみを回収する。
【００１２】前記プログラム域とそのスレッドに持つシ
ステム資源の回収は、プログラム域管理制御表が使用し
ていた領域を回収することにより行うことができる。本
発明は、上記第２の目的を達成するため、空間内に１又
は複数のタスクを有し、前記タスク内に１又は複数のス
レッドを有し、前記タスク単位でファイル管理制御表を
用いてファイル管理を行い、前記スレッド単位でプログ
ラム域管理制御表を用いてプログラム管理を行う資源管
理方法において、動的なプログラム回収要求時には、プ
ログラム域のみを回収する。
ステム資源の回収は、プログラム域管理制御表が使用し
ていた領域を回収することにより行うことができる。本
発明は、上記第２の目的を達成するため、空間内に１又
は複数のタスクを有し、前記タスク内に１又は複数のス
レッドを有し、前記タスク単位でファイル管理制御表を
用いてファイル管理を行い、前記スレッド単位でプログ
ラム域管理制御表を用いてプログラム管理を行う資源管
理方法において、動的なプログラム回収要求時には、プ
ログラム域のみを回収する。
【００１３】なお、動的なプログラム回収要求時とは、
前述した空間、タスク、スレッドと言った資源の回収契
機による回収要求ではなく、ユーザが陽にプログラム域
の回収要求を行うことを言う。前記プログラム域の回収
は、プログラム域として使っていた領域を回収し、プロ
グラム域管理制御表で管理しているプログラム域の開始
アドレスをクリアすることにより行うことができる。
前述した空間、タスク、スレッドと言った資源の回収契
機による回収要求ではなく、ユーザが陽にプログラム域
の回収要求を行うことを言う。前記プログラム域の回収
は、プログラム域として使っていた領域を回収し、プロ
グラム域管理制御表で管理しているプログラム域の開始
アドレスをクリアすることにより行うことができる。
【００１４】
【作用】本発明では、プログラム域の管理をプログラム
域のスコープであるスレッドだけで管理するのではな
く、その上位の実行単位であるタスクでも管理すること
を特長としている。このため、マルチタスクにおいて
は、スレッド終了時にはスレッドで管理している資源の
みを回収し、タスクで管理している資源は回収しないこ
とにより、回収すべき資源の量を減らしてスレッド終了
時の実行性能を向上させる。また、スレッドの再生成時
には、回収しなかったシステム資源を再利用することに
より、スレッド再生成時の実行性能を向上させる。
域のスコープであるスレッドだけで管理するのではな
く、その上位の実行単位であるタスクでも管理すること
を特長としている。このため、マルチタスクにおいて
は、スレッド終了時にはスレッドで管理している資源の
みを回収し、タスクで管理している資源は回収しないこ
とにより、回収すべき資源の量を減らしてスレッド終了
時の実行性能を向上させる。また、スレッドの再生成時
には、回収しなかったシステム資源を再利用することに
より、スレッド再生成時の実行性能を向上させる。
【００１５】シングルタスクにおいては、動的なプログ
ラム域の回収要求時にはプログラム域のみを回収し、ス
レッドで管理している資源は回収しないことにより、回
収すべき資源の量を減らして動的なプログラム域の回収
要求時の実行性能を向上させる。また、プログラム域の
再生成には、回収しなかったプログラム域を再利用する
ことにより、プログラム域の再生成時の実行性能を向上
させる。
ラム域の回収要求時にはプログラム域のみを回収し、ス
レッドで管理している資源は回収しないことにより、回
収すべき資源の量を減らして動的なプログラム域の回収
要求時の実行性能を向上させる。また、プログラム域の
再生成には、回収しなかったプログラム域を再利用する
ことにより、プログラム域の再生成時の実行性能を向上
させる。
【００１６】
【実施例】始めに、本発明の資源管理方法が適用される
各種空間の構造について図４〜図６を用いて説明する。
空間は、プログラムの実行環境や実行形態の違いから、
例えば、バッチと会話処理用の空間、通信アプリケーシ
ョン空間、ＧＳ空間の３種類に分けられる。
各種空間の構造について図４〜図６を用いて説明する。
空間は、プログラムの実行環境や実行形態の違いから、
例えば、バッチと会話処理用の空間、通信アプリケーシ
ョン空間、ＧＳ空間の３種類に分けられる。
【００１７】図４は、シングルタスクの環境であるバッ
チと会話処理用の空間の構造を示す。バッチと会話処理
用の空間７は、空間内で１つのタスク２と１つのスレッ
ド３が動作する形態で構成される。この空間７で動作す
るアプリケーションプログラムにとっては、プログラム
実行体が空間７、タスク２、スレッド３から構成されて
いることはあまり重要なことではない。アプリケーショ
ンプログラムは、空間７内の全資源を専有して走行す
る。このように１空間、１タスク、１スレッドが縮退し
てプログラム実行体を形成する形態はプロセスと呼ばれ
る。
チと会話処理用の空間の構造を示す。バッチと会話処理
用の空間７は、空間内で１つのタスク２と１つのスレッ
ド３が動作する形態で構成される。この空間７で動作す
るアプリケーションプログラムにとっては、プログラム
実行体が空間７、タスク２、スレッド３から構成されて
いることはあまり重要なことではない。アプリケーショ
ンプログラムは、空間７内の全資源を専有して走行す
る。このように１空間、１タスク、１スレッドが縮退し
てプログラム実行体を形成する形態はプロセスと呼ばれ
る。
【００１８】バッチと会話処理用の空間７は、個々のア
プリケーションプログラムやユーティリティプログラム
が実行される度に作成され、そのプログラムの終了とと
もに削除される。図５は、マルチタスクの環境である通
信アプリケーション空間の構造を示す。通信アプリケー
ション空間８では、１つの空間で複数のタスク２，２が
多重に走行する。個々のタスク２ではそれぞれ１つのス
レッド１が走行してアプリケーションプログラムを実行
する。個々のタスク２で動作するファイルは、タスクの
独立性の高いプログラム実行環境下で、空間８内の他タ
スクの存在を殆ど意識しないで走行することができる。
１０は事前オープンファイル環境である。
プリケーションプログラムやユーティリティプログラム
が実行される度に作成され、そのプログラムの終了とと
もに削除される。図５は、マルチタスクの環境である通
信アプリケーション空間の構造を示す。通信アプリケー
ション空間８では、１つの空間で複数のタスク２，２が
多重に走行する。個々のタスク２ではそれぞれ１つのス
レッド１が走行してアプリケーションプログラムを実行
する。個々のタスク２で動作するファイルは、タスクの
独立性の高いプログラム実行環境下で、空間８内の他タ
スクの存在を殆ど意識しないで走行することができる。
１０は事前オープンファイル環境である。
【００１９】通信アプリケーション空間８は、アプリケ
ーションプログラムが処理を開始する以前に前もって作
成され、停止時に削除される。これらの空間８では、ア
プリケーションプログラムが使用するファイルを空間作
成時に事前にオープンしておくことが可能である。これ
によって、タスクで動作するアプリケーションプログラ
ムは、少ないオーバヘッドでファイルを使用できるよう
になる。
ーションプログラムが処理を開始する以前に前もって作
成され、停止時に削除される。これらの空間８では、ア
プリケーションプログラムが使用するファイルを空間作
成時に事前にオープンしておくことが可能である。これ
によって、タスクで動作するアプリケーションプログラ
ムは、少ないオーバヘッドでファイルを使用できるよう
になる。
【００２０】図６は、シングルタスクの環境であるＧＳ
空間の構造を示す。ＯＳの各サーバ空間をＧＳ（Global
Service）空間と言う。ＧＳ空間９では、タスク２が１
つだけ存在し、その中で複数のスレッド３，３が走行す
る。クライアントからの処理要求は、それぞれが軽量な
スレッドで高速に処理される。ＧＳ空間９では、タスク
２はあまり重要な役割を果たさない。
空間の構造を示す。ＯＳの各サーバ空間をＧＳ（Global
Service）空間と言う。ＧＳ空間９では、タスク２が１
つだけ存在し、その中で複数のスレッド３，３が走行す
る。クライアントからの処理要求は、それぞれが軽量な
スレッドで高速に処理される。ＧＳ空間９では、タスク
２はあまり重要な役割を果たさない。
【００２１】このＧＳ空間９は、システム始動時又は s
tartgsユーティリティ実行時に作成され、システム停止
時又はstopgsユーティリティ実行時に削除される。本発
明は、上記各種空間のうち、通信アプリケーション空間
８のようなマルチタスクの環境を必要とするシステムに
おいても、バッチと会話処理用の空間７及びＧＳ空間９
のようなシングルタスクの環境においても有効である。
tartgsユーティリティ実行時に作成され、システム停止
時又はstopgsユーティリティ実行時に削除される。本発
明は、上記各種空間のうち、通信アプリケーション空間
８のようなマルチタスクの環境を必要とするシステムに
おいても、バッチと会話処理用の空間７及びＧＳ空間９
のようなシングルタスクの環境においても有効である。
【００２２】次に、本実施例におけるプログラム域とシ
ステム資源の関係を図７を用いて説明する。図７におい
て、１１はタスク資源表、１２はファイル管理制御表で
ある。ファイル管理制御表１２はタスク資源であり、フ
ァイル単位にチェーンが続く。ファイル管理制御表１２
には、ファイルの排他、ファイルリードに必要な情報等
のファイルのオープン環境が記録されている。
ステム資源の関係を図７を用いて説明する。図７におい
て、１１はタスク資源表、１２はファイル管理制御表で
ある。ファイル管理制御表１２はタスク資源であり、フ
ァイル単位にチェーンが続く。ファイル管理制御表１２
には、ファイルの排他、ファイルリードに必要な情報等
のファイルのオープン環境が記録されている。
【００２３】１３はスレッド資源表、１４はプログラム
域管理制御表である。プログラム域管理制御表１４はス
レッド資源であり、プログラム単位にチェーンが続く。
プログラム域環境制御表１４には、ファイル管理制御表
１２をポイントするファイルのオープン環境と、プログ
ラム域１５の開始アドレスとサイズ等のプログラム域管
理が記録されている。１５はプログラム域である。
域管理制御表である。プログラム域管理制御表１４はス
レッド資源であり、プログラム単位にチェーンが続く。
プログラム域環境制御表１４には、ファイル管理制御表
１２をポイントするファイルのオープン環境と、プログ
ラム域１５の開始アドレスとサイズ等のプログラム域管
理が記録されている。１５はプログラム域である。
【００２４】次に、プログラム域の回収要求時とプログ
ラム域の再獲得要求時の処理フローを図１及び図２を用
いて説明する。図１の処理フローは、プログラム域の回
収要求時にスタートする。プログラムの実行体である空
間、タスク、スレッドの各実行体が終了する際、各実行
体が持つ資源の自動回収が行われる。例えば、スレッド
と言う実行体が終了する際、スレッド資源を持つコンポ
ーネントに対して資源の回収要求が行われる。ここで言
うスレッド終了時の回収要求とは、この要求のことをい
う。ここで、本発明に関するコンポーネントはスレッド
資源を持つので、スレッド終了時にシステムからスレッ
ド資源回収の契機がもらえる。このときにスレッド資源
を必要に応じて回収する。
ラム域の再獲得要求時の処理フローを図１及び図２を用
いて説明する。図１の処理フローは、プログラム域の回
収要求時にスタートする。プログラムの実行体である空
間、タスク、スレッドの各実行体が終了する際、各実行
体が持つ資源の自動回収が行われる。例えば、スレッド
と言う実行体が終了する際、スレッド資源を持つコンポ
ーネントに対して資源の回収要求が行われる。ここで言
うスレッド終了時の回収要求とは、この要求のことをい
う。ここで、本発明に関するコンポーネントはスレッド
資源を持つので、スレッド終了時にシステムからスレッ
ド資源回収の契機がもらえる。このときにスレッド資源
を必要に応じて回収する。
【００２５】同様に、タスクと言う実行体が終了する際
にも、システムはタスク資源を持つコンポーネントに対
して資源の回収要求を行う。この要求がタスク終了時の
回収要求である。また、上記の空間、タスク、スレッド
といった資源の回収契機による回収要求でなく、ユーザ
が陽にプログラム域の回収要求を行う動的なプログラム
域の回収要求も行われる。具体的には、スーパバイザが
ユーザ向けにプログラム域を回収する関数を用意してお
り、ユーザはこの関数を使ってプログラム域の回収をス
ーババイザに要求する。主なコンポーネントとしては、
シェルがあり、その使用目的は時空間（シェル空間のこ
と）の仮想領域が有限であることから、資源の有効利用
のために利用される。
にも、システムはタスク資源を持つコンポーネントに対
して資源の回収要求を行う。この要求がタスク終了時の
回収要求である。また、上記の空間、タスク、スレッド
といった資源の回収契機による回収要求でなく、ユーザ
が陽にプログラム域の回収要求を行う動的なプログラム
域の回収要求も行われる。具体的には、スーパバイザが
ユーザ向けにプログラム域を回収する関数を用意してお
り、ユーザはこの関数を使ってプログラム域の回収をス
ーババイザに要求する。主なコンポーネントとしては、
シェルがあり、その使用目的は時空間（シェル空間のこ
と）の仮想領域が有限であることから、資源の有効利用
のために利用される。
【００２６】プログラム域の回収要求があると、ステッ
プＳ１１において、プログラム域の回収が行われる。プ
ログラム域の回収とは、プログラム域１５として使って
いた領域を回収し、プログラム域管理制御表１４で管理
しているプログラム域１５の開始アドレスをクリアする
ことを言う。次に、ステップＳ１２で、プログラム域の
回収要求がスレッド又はタスク終了時の回収要求である
か否かが判定される。もし、前述の動的なプログラム域
の回収要求であれば、ステップＳ１１のプログラム域の
回収のみで処理を終了する。
プＳ１１において、プログラム域の回収が行われる。プ
ログラム域の回収とは、プログラム域１５として使って
いた領域を回収し、プログラム域管理制御表１４で管理
しているプログラム域１５の開始アドレスをクリアする
ことを言う。次に、ステップＳ１２で、プログラム域の
回収要求がスレッド又はタスク終了時の回収要求である
か否かが判定される。もし、前述の動的なプログラム域
の回収要求であれば、ステップＳ１１のプログラム域の
回収のみで処理を終了する。
【００２７】スレッド又はタスク終了時の回収要求であ
る場合はステップＳ１３へ進み、スレッドに持つ資源の
回収を行う。スレッドに持つ資源の回収とは、プログラ
ム域管理制御表１４で使っていた領域を回収することを
言う。ステップＳ１４では、回収要求がタスク終了時の
回収要求であるか否かが判定される。回収要求がスレッ
ド終了時の回収要求であれば、ステップＳ１１のプログ
ラム域の回収とステップＳ１３のスレッドに持つ資源の
回収のみで処理を終了する。
る場合はステップＳ１３へ進み、スレッドに持つ資源の
回収を行う。スレッドに持つ資源の回収とは、プログラ
ム域管理制御表１４で使っていた領域を回収することを
言う。ステップＳ１４では、回収要求がタスク終了時の
回収要求であるか否かが判定される。回収要求がスレッ
ド終了時の回収要求であれば、ステップＳ１１のプログ
ラム域の回収とステップＳ１３のスレッドに持つ資源の
回収のみで処理を終了する。
【００２８】タスク終了時の回収要求である場合は、ス
テップＳ１５へ進み、タスクに持つ資源の回収を行い処
理を終了する。タスクに持つ資源の回収とは、ファイル
管理制御表１２で使っていた領域を回収し、またこのフ
ァイル管理制御表１２が管理していた情報であるファイ
ルのオープン環境の返却を言う。タスク終了時の回収要
求の場合は、ステップＳ１１のプログラム域の回収と、
ステップＳ１３のスレッドに持つ資源の回収と、ステッ
プＳ１５のタスクに持つ資源の回収が行われる。
テップＳ１５へ進み、タスクに持つ資源の回収を行い処
理を終了する。タスクに持つ資源の回収とは、ファイル
管理制御表１２で使っていた領域を回収し、またこのフ
ァイル管理制御表１２が管理していた情報であるファイ
ルのオープン環境の返却を言う。タスク終了時の回収要
求の場合は、ステップＳ１１のプログラム域の回収と、
ステップＳ１３のスレッドに持つ資源の回収と、ステッ
プＳ１５のタスクに持つ資源の回収が行われる。
【００２９】図２の処理フローは、プログラム域の再獲
得要求時にスタートする。プログラム域の再獲得要求が
あると、ステップＳ２１でスレッドに持つ該当システム
資源があるか否かが判定され、ステップＳ２２でタスク
に持つ該当システム資源があるか否かが判定される。ス
レッドに持つ該当システム資源及びタスクに持つ該当シ
ステム資源が共になければ、ステップＳ２３でタスクに
持つ該当システム資源の獲得が行われ、ステップＳ２４
でスレッドに持つシステム資源の獲得が行われ、ステッ
プＳ２５でプログラム域の獲得が行われる。
得要求時にスタートする。プログラム域の再獲得要求が
あると、ステップＳ２１でスレッドに持つ該当システム
資源があるか否かが判定され、ステップＳ２２でタスク
に持つ該当システム資源があるか否かが判定される。ス
レッドに持つ該当システム資源及びタスクに持つ該当シ
ステム資源が共になければ、ステップＳ２３でタスクに
持つ該当システム資源の獲得が行われ、ステップＳ２４
でスレッドに持つシステム資源の獲得が行われ、ステッ
プＳ２５でプログラム域の獲得が行われる。
【００３０】ここで、タスクに持つシステム資源の獲得
とは、ファイル管理制御表１２としての領域を獲得し、
このファイル管理制御表１２にファイルのオープン環境
を構築することを言う。スレッドに持つシステム資源の
獲得とは、プログラム域管理制御表１４としての領域を
獲得し、このプログラム域管理制御表１４にファイルの
オープン環境とて使う資源表をポイントし、プログラム
域のサイズを設定することを言う。
とは、ファイル管理制御表１２としての領域を獲得し、
このファイル管理制御表１２にファイルのオープン環境
を構築することを言う。スレッドに持つシステム資源の
獲得とは、プログラム域管理制御表１４としての領域を
獲得し、このプログラム域管理制御表１４にファイルの
オープン環境とて使う資源表をポイントし、プログラム
域のサイズを設定することを言う。
【００３１】プログラム域の獲得とは、プログラム域と
しての領域を獲得し、この領域にプログラムの内容を読
み込み、必要ならば再配置等の処理も行い、この獲得し
たアドレスをプログラム域の開始アドレスとしてプログ
ラム域管理制御表１４に設定することを言う。スレッド
に持つ該当システム資源があり、タスクに持つ該当シス
テム資源がない場合は、ステップＳ２４でスレッドに持
つシステム資源の獲得が行われ、ステップＳ２５でプロ
グラム域のみの獲得が行われる。
しての領域を獲得し、この領域にプログラムの内容を読
み込み、必要ならば再配置等の処理も行い、この獲得し
たアドレスをプログラム域の開始アドレスとしてプログ
ラム域管理制御表１４に設定することを言う。スレッド
に持つ該当システム資源があり、タスクに持つ該当シス
テム資源がない場合は、ステップＳ２４でスレッドに持
つシステム資源の獲得が行われ、ステップＳ２５でプロ
グラム域のみの獲得が行われる。
【００３２】また、スレッドに持つ該当システム資源あ
る場合には、ステップＳ２５でプログラム域のみの獲得
が行われる。図８は、資源の回収状態を従来の方法と比
較している。この表を見ても分かるように動的なプログ
ラム域の回収要求ではプログラム域だけしか回収しない
ため、回収すべき資源の量を減少させる。また、同じプ
ログラム域に対する再獲得要求については単にプログラ
ム域の獲得だけで処理が完結する。
る場合には、ステップＳ２５でプログラム域のみの獲得
が行われる。図８は、資源の回収状態を従来の方法と比
較している。この表を見ても分かるように動的なプログ
ラム域の回収要求ではプログラム域だけしか回収しない
ため、回収すべき資源の量を減少させる。また、同じプ
ログラム域に対する再獲得要求については単にプログラ
ム域の獲得だけで処理が完結する。
【００３３】また、スレッド終了時の回収要求では、プ
ログラム域とスレッドに持つシステム資源だけを回収す
るため、回収すべき資源の量を減少させる。また、スレ
ッド再生時の再獲得要求については、プログラム域とス
レッドに持つシステム資源だけの獲得で処理が完結す
る。このため、従来と同じ再獲得要求については処理量
がすくなくなり、実行性能を向上させることができる。
ログラム域とスレッドに持つシステム資源だけを回収す
るため、回収すべき資源の量を減少させる。また、スレ
ッド再生時の再獲得要求については、プログラム域とス
レッドに持つシステム資源だけの獲得で処理が完結す
る。このため、従来と同じ再獲得要求については処理量
がすくなくなり、実行性能を向上させることができる。
【００３４】以上説明した資源管理方法は、シングルタ
スクに関しては、動的なプログラム域の回収要求と、プ
ログラム域の再獲得要求の場合に有効である。また、マ
ルチタスクに関しては、タスクの環境を再利用する場合
に有効である。なお、タスクが終了する場合はスレッド
に持つ資源、及びタスクに持つ資源を全て回収するの
で、本発明がタスク単位に実現するアプリケーションの
活性保守を妨げることはない。
スクに関しては、動的なプログラム域の回収要求と、プ
ログラム域の再獲得要求の場合に有効である。また、マ
ルチタスクに関しては、タスクの環境を再利用する場合
に有効である。なお、タスクが終了する場合はスレッド
に持つ資源、及びタスクに持つ資源を全て回収するの
で、本発明がタスク単位に実現するアプリケーションの
活性保守を妨げることはない。
【００３５】
【発明の効果】以上説明したように、本発明によれば、
資源管理方法において、スレッド終了時とスレッド再生
時の実行性能を向上させ、更に、動的なプログラム域の
回収要求時とプログラム域の再獲得要求時までも実行性
能を向上させることができる。
資源管理方法において、スレッド終了時とスレッド再生
時の実行性能を向上させ、更に、動的なプログラム域の
回収要求時とプログラム域の再獲得要求時までも実行性
能を向上させることができる。
【図１】本発明の実施例のプログラム域の回収要求時の
処理フローを示すフローチャート。
処理フローを示すフローチャート。
【図２】本発明の実施例のプログラム域の再獲得要求時
の処理フローを示すフローチャート。
の処理フローを示すフローチャート。
【図３】プログラムの実行体の構成を示す図。
【図４】バッチと会話処理用の空間の構造を示す図。
【図５】通信アプリケーション空間の構造を示す図。
【図６】ＧＳ空間の構造を示す図。
【図７】プログラム域とシステム資源の関係を示す図。
【図８】本発明の実施例による資源の回収状態と、従来
例による資源の回収状態を比較して示す図。
例による資源の回収状態を比較して示す図。
１…空間 ２…タスク ３…スレッド ４…空間資源 ５…タスク資源 ６…スレッド資源 ７…バッチと会話処理用の空間 ８…通信アプリケーション空間 ９…ＧＳ空間 １０…事前オープンファイル環境 １１…タスク資源表 １２…ファイル管理制御表 １３…スレッド資源表 １４…プログラム域管理制御表 １５…プログラム域
Claims (4)
- 【請求項１】 空間内に１又は複数のタスクを有し、前
記タスク内に１又は複数のスレッドを有し、前記タスク
単位でファイル管理制御表を用いてファイル管理を行
い、前記スレッド単位でプログラム域管理制御表を用い
てプログラム管理を行う資源管理方法において、スレッ
ド終了時には、プログラム域とそのスレッドに持つシス
テム資源のみを回収することを特徴とする資源管理方
法。 - 【請求項２】 前記プログラム域とそのスレッドに持つ
システム資源の回収は、前記プログラム域管理制御表が
使用していた領域を回収することにより行うことを特徴
とする請求項１記載の資源管理方法。 - 【請求項３】 空間内に１又は複数のタスクを有し、前
記タスク内に１又は複数のスレッドを有し、前記タスク
単位でファイル管理制御表を用いてファイル管理を行
い、前記スレッド単位でプログラム域管理制御表を用い
てプログラム管理を行う資源管理方法において、動的な
プログラム回収要求時には、プログラム域のみを回収す
ることを特徴とする資源管理方法。 - 【請求項４】 前記プログラム域の回収は、プログラム
域として使っていた領域を回収し、前記プログラム域管
理制御表で管理しているプログラム域の開始アドレスを
クリアすることにより行われることを特徴とする請求項
１記載の資源管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP25540394A JPH08123700A (ja) | 1994-10-20 | 1994-10-20 | 資源管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP25540394A JPH08123700A (ja) | 1994-10-20 | 1994-10-20 | 資源管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH08123700A true JPH08123700A (ja) | 1996-05-17 |
Family
ID=17278286
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP25540394A Withdrawn JPH08123700A (ja) | 1994-10-20 | 1994-10-20 | 資源管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH08123700A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1164485A2 (en) * | 2000-05-15 | 2001-12-19 | Matsushita Electric Industrial Co., Ltd. | Apparatus and method for collecting resources which became unnecessary |
| WO2007052442A1 (ja) * | 2005-10-31 | 2007-05-10 | Sony Computer Entertainment Inc. | 情報処理方法および情報処理装置 |
| WO2007052443A1 (ja) * | 2005-10-31 | 2007-05-10 | Sony Computer Entertainment Inc. | 情報処理方法および情報処理装置 |
-
1994
- 1994-10-20 JP JP25540394A patent/JPH08123700A/ja not_active Withdrawn
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1164485A2 (en) * | 2000-05-15 | 2001-12-19 | Matsushita Electric Industrial Co., Ltd. | Apparatus and method for collecting resources which became unnecessary |
| US7024668B2 (en) | 2000-05-15 | 2006-04-04 | Matsushita Electric Industrial Co., Ltd. | Application execution apparatus and method |
| EP1164485A3 (en) * | 2000-05-15 | 2006-10-18 | Matsushita Electric Industrial Co., Ltd. | Apparatus and method for collecting resources which became unnecessary |
| US8028289B2 (en) | 2000-05-15 | 2011-09-27 | Panasonic Corporation | Application execution apparatus and method for managing special threads to notify listeners of resource status changes |
| WO2007052442A1 (ja) * | 2005-10-31 | 2007-05-10 | Sony Computer Entertainment Inc. | 情報処理方法および情報処理装置 |
| WO2007052443A1 (ja) * | 2005-10-31 | 2007-05-10 | Sony Computer Entertainment Inc. | 情報処理方法および情報処理装置 |
| US8161161B2 (en) | 2005-10-31 | 2012-04-17 | Sony Computer Entertainment, Inc. | Information processing method and information processing apparatus |
| US8490104B2 (en) | 2005-10-31 | 2013-07-16 | Sony Corporation | Method and apparatus for reservation and reallocation of surplus resources to processes in an execution space by a local resource manager after the execution space is generated succeeding the initialization of an application for which the execution space is created and the resources are allocated to the execution space by a global resource manager prior to application execution |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6250189B2 (ja) | データストリームのためのクライアント構成可能なセキュリティオプション | |
| US10338958B1 (en) | Stream adapter for batch-oriented processing frameworks | |
| US9858322B2 (en) | Data stream ingestion and persistence techniques | |
| EP3069228B1 (en) | Partition-based data stream processing framework | |
| EP3069274B1 (en) | Managed service for acquisition, storage and consumption of large-scale data streams | |
| JP4436036B2 (ja) | 情報処理装置、トレース処理方法、プログラム及び記録媒体 | |
| EP3069275A1 (en) | Data stream ingestion and persistence techniques | |
| US20200310963A1 (en) | Real-time replicating garbage collection | |
| US11620215B2 (en) | Multi-threaded pause-less replicating garbage collection | |
| CN110895484A (zh) | 任务调度方法及装置 | |
| CN110895487A (zh) | 分布式任务调度系统 | |
| CN113282649A (zh) | 分布式任务的处理方法、装置和计算机设备 | |
| US20070050683A1 (en) | Virtual flight recorder hosted by system tracing facility | |
| CN110895483A (zh) | 任务恢复方法及装置 | |
| CN110895488A (zh) | 任务调度方法及装置 | |
| Liu et al. | Optimizing shuffle in wide-area data analytics | |
| JP5030647B2 (ja) | 複数処理ノードを含むコンピュータ・システムでプログラムをロードする方法、該プログラムを含むコンピュータ可読媒体、及び、並列コンピュータ・システム | |
| CN110895486A (zh) | 分布式任务调度系统 | |
| JPH08123700A (ja) | 資源管理方法 | |
| US12093122B2 (en) | Intelligent log analysis and retention for microservices applications | |
| JP3919274B2 (ja) | 状態記録再現機能を有する計算機システム及び状態記録再現プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| CN104516778A (zh) | 一种多任务环境下进程检查点的保存与恢复系统及方法 | |
| JPH07271620A (ja) | ソフトウェア回復方式 | |
| CN117908988A (zh) | 从服务器内存按需加载运行程序内容的方法及系统 | |
| CN113986688A (zh) | 云管理平台监听资源创建的方法、存储介质和云服务系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A761 | Written withdrawal of application |
Effective date: 20040401 Free format text: JAPANESE INTERMEDIATE CODE: A761 |