JPH0793170A - 通信バッファ管理装置 - Google Patents

Abstract

(57)【要約】 【目的】 同時に処理を要求する複数の通信リンクに対
し公平な通信サービスを与え、バッファフルによる一時
受信停止後にも受信を再開し、更に通信制御システムの
不具合によるバッファ管理障害の検出が容易な通信バッ
ファ管理装置を得る。 【構成】 利用可能な残存バッファ量を記憶するバッフ
ァ残存量テーブルと、残存バッファ量から各タスク毎に
割りつけられるタスク使用バッファ量を記憶するタスク
使用バッファ量テーブルとを備え、残存バッファ量が所
定の下限値より小さくなるかまたはタスクで使用するバ
ッファ量が別の設定上限値よりも大きくなると上記残存
バッファの使用を停止して要求元のタスクに通知し、残
存バッファ量が所定の下限値より大きくなりかつ各タス
クで使用するバッファ量が別の設定上限値よりも小さく
なると、残存バッファの使用を再開するようにした。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、通信制御システムで
の共通バッファの公平で有効な使用と利用性の向上に関
するものである。

【０００２】

【従来の技術】通信バッファの有効利用に関連する従来
技術は以下に述べるものがある。例えば、特開平０４−
１５８４２では共に詳細な処理は不明であるが、バッフ
ァプールの使用量監視、及びバッファの枯渇予測に関す
る技術が述べられている。即ち、使用量監視と枯渇予測
をシステム全体と通信リンク単位で行ない、枯渇発生が
予測された場合にはシステム外部への枯渇警告通知、及
び枯渇履歴の採取を行なった後に自動的にシステムのリ
セット／再起動（ＩＰＬ）を行なっている。また、特開
平０５−２８０３７ではバッファ獲得／解放が行なわれ
る度に逐次その履歴を記録領域に記録し、記録領域が一
杯になったら記録を外部記憶装置に書き出させ、この外
部記憶装置に書き出された履歴を参照することで通信制
御システムのバッファ使用状況を監視する。特開昭６２
−２１６０６０ではバッファの一部にバッファ獲得要求
元及び解放要求元の情報をセットしておき、障害発生時
に各バッファに係わった処理の情報を素早く得られるよ
うにしている。

【０００３】

【発明が解決しようとする課題】従来の技術は上記のよ
うな目的と構成であり、バッファ枯渇発生時に通信制御
システムが自動的に停止／初期化／再起動されてしまう
システムでは通信業務は全て強制的に中断／異常終了さ
せられてしまう。また、特開平０５−２８０３７ではバ
ッファの使用状況が通信制御システム外部に記録される
だけであり、バッファが枯渇した際の制御については特
に決めていない。更に、特開昭６２−２１６０６０では
バッファ獲得／解放要求元に関する情報は個々のバッフ
ァに記録されるが、バッファ処理に関する障害の発生を
即座に検出することはできないという課題があった。

【０００４】この発明は、上記のような課題を解消する
ためになされたもので、通信制御システムのメモリ資源
を有効に使用するために、通信制御システムにおいて使
用するバッファの総量を有限の大きさ以下に保つように
常に制御する。また、複数の通信リンクを同時に扱う場
合、単一の通信リンクが一度に大量のバッファを使用し
て他の通信リンクを圧迫することがないよう、つまり各
通信リンクに提供するデータ伝送サービスを公平にする
ように単一の通信リンクが一度に確保できるバッファ量
を一定の大きさ以下に抑えることを目的とする。更に、
バッファの空き状況に応じて通信リンク毎の通信データ
受信処理の一時停止／再開を制御して通信処理業務を継
続できるようにすることを目的とする。この他に、バッ
ファ処理に障害が発生した場合に即座にその障害を検出
し、通信制御システムの不具合を解析できる様にするこ
とも目的とする。

【０００５】

【課題を解決するための手段】この発明に係わる通信バ
ッファ管理装置は、利用可能な残存バッファ量を記憶す
るバッファ残存量テーブルと、この残存バッファ量から
各タスク毎に割りつけられるタスク使用バッファ量を記
憶するタスク使用バッファ量テーブルとを備え、残存バ
ッファ量が所定の下限値より小さくなるかまたはタスク
で使用するバッファ量が別の設定上限値よりも大きくな
ると上記残存バッファの使用を停止して要求元のタスク
に通知し、上記残存バッファ量が所定の下限値より大き
くなりかつ各タスクで使用するバッファ量が別の設定上
限値よりも小さくなると、残存バッファの使用を再開す
るようにした。また請求項２の通信バッファ管理装置
は、請求項１の装置に更に、各タスクには処理優先度を
設定し、タスク使用バッファ量テーブルは優先度も含め
て記憶し、残存バッファの使用を停止または再開する際
に優先度も参照して決定するようにした。

【０００６】請求項３の通信バッファ管理装置は、請求
項１の装置に更に、各タスクが使用するバッファには使
用バッファサイズとタスクリンク情報とを記載し、また
各バッファの割りつけ・解放を行うバッファ管理モジュ
ールを備え、残存バッファの使用が停止された場合は対
応タスクのリンク情報を蓄積するキュー・バッファをも
備え、残存バッファの使用／停止／再開はバッファ管理
モジュールとキュー・バッファを用いて行うようにし
た。また請求項４の通信バッファ管理装置は、各バッフ
ァの割りつけ・解放を行いまたバッファ解放時の処理を
行う解放処理ルーチンを持つバッファ管理モジュールを
備え、各タスクが使用するバッファには、当該使用バッ
ファを解放する上記解放処理ルーチンのアドレスを記憶
するようにした。

【０００７】

【作用】この発明における通信バッファ管理装置は、残
存バッファの量が相対的に所定の値よりも小さくなる
と、残存バッファの割り付けを要求したタスクにバッフ
ァの使用停止を通知し、残存バッファ量が相対的に所定
値より大きくなると、バッファを割り付けて使用を再開
する。請求項２の装置は、バッファの割り付けまたは再
開に際して各タスクの優先度も参照される。請求項３の
装置は、バッファの管理・割り付けはバッファ管理モジ
ュールが行い、各タスクのバッファの使用／停止はキュ
ー・バッファに蓄積されて管理・実行される。請求項４
の装置は、各タスクが使用するバッファには解放処理ル
ーチンのアドレスが記憶され、従って例えばバッファ管
理が不正になった場合には、処理停止時の履歴が保持さ
れる。

【０００８】

【実施例】

実施例１．一般のデータ処理用のバッファ・メモリの分
割管理にいわゆるオペレーティング・システムがタスク
間の負荷調整をしてきめ細かく管理しているのに対し、
通信制御用のバッファの管理に関しては共通の通信バッ
ファの管理までは見られなかったのが現状である。そこ
で受信処理に必要なバッファ量を把握し、バッファ管理
手段にあるテーブル部分を用意して、これらの数値から
バッファ管理手段が簡便にバッファ使用を平等化する。
本発明の実施例を図に基づいて説明する。図１は本発明
の一実施例である通信バッファ管理装置を含む通信制御
装置の構成を示す図である。図において、１は通信バッ
ファ全体、２は通信バッファ全体１から切り出されてタ
スク毎に使用されるバッファ、３はディスパッチャ、４
は通信制御システム外部からの通信データを入力する通
信リンクである。５は各通信リンク毎に存在し、通信リ
ンクから通信データを読み込む受信タスク、６は受信タ
スク毎に存在する使用バッファ量を記したＴＣＢ（タス
ク制御ブロック）である。７は処理が可能なタスクのＴ
ＣＢを保持するＲＥＡＤＹキュー、８はバッファの割り
付け解放と、受信タスクの起動スケジューリング処理を
担当するバッファ管理モジュール、９はバッファ管理モ
ジュール中のバッファ獲得処理ルーチン、１０はバッフ
ァ管理モジュールが管理する通信バッファ残存領域の大
きさを記したＢＣＢ（バッファ制御ブロック）、１１は
バッファ管理モジュール中のバッファ解放処理ルーチン
である。１２はプロトコル処理タスクで、１３は個別Ｓ
ＵＳＰＥＮＤＥＤキュー、１４は全体ＳＵＳＰＥＮＤＥ
Ｄキュー、１５は通信リンク毎に存在し、通信リンクへ
通信データを書き出す送信タスク、１６は通信制御シス
テムから通信データを外部へ出力する通信リンクであ
る。

【０００９】図２は各バッファ２の構造を示した図であ
る。図において、２−ａはバッファサイズ記録領域、２
−ｂはＴＣＢアドレス記録領域、２−ｃはバッファ解放
処理ルーチンアドレス記録領域、２−ｄは通信データ保
持領域である。図３は各受信タスクが使用するタスク使
用バッファ量を記憶するＴＣＢ６の構造を示した図であ
り、図において、６−ａはタスク使用バッファ量記憶テ
ーブルである。図４は利用可能な残存バッファ量を記憶
するＢＣＢ１０の構造を示した図であり、図において、
１０−ａはシステム全体の通信バッファ残存量記憶テー
ブルである。また、図５はディパッチャの処理を示すフ
ローチャート図、図６は受信タスクの処理を示すフロー
チャート図、図７はバッファ獲得処理ルーチンの処理を
示すフローチャート図、図８はバッファ解放処理ルーチ
ンの処理を示すフローチャート図である。

【００１０】本実施例では、各バッファ２の割り付け・
解放を行うバッファ管理モジュールを別に設けた例を説
明する。更に、バッファ使用停止時のＳＵＳＰＥＮＤＥ
Ｄキュー１３、１４も設けた例である。通信バッファ１
とバッファ２の使用状況の監視と制御は以下の様にして
行なう。ディスパッチャ３は、図５で示すように受信用
通信リンク４の監視を行なうが、個々の通信リンク４に
対応して存在する受信タスク５は、ステップ３−ａで受
信データが到着するまで休止状態にある。通信リンク４
上に受信データが到着すると、ステップ３−ｂでディス
パッチャ３は当該通信リンク４に対応づけられた受信タ
スク５のＴＣＢ６をＲＥＡＤＹキュー７に入れる。次に
ディスパッチャ３は、ステップ３−ｃでＲＥＡＤＹキュ
ー７の先頭から一つづつＴＣＢ６を取りだし、対応する
受信タスク５に実行を開始させる。この処理は、ステッ
プ３−ｄとしてＲＥＡＤＹキュー７が空になるまで続け
られる。受信処理の結果、ステップ３−ｅでシステム外
部からシステム停止が指示された場合は終了処理の後シ
ステムは停止する。さもなくば、ディスパッチャ３は再
び受信データの到着を待つ。

【００１１】ディスパッチャ３に実行権を譲渡された受
信タスク５は、図６で受信データを通信リンク４から読
み込んだ後保持するメモリ領域としてバッファ２を使用
するため、ステップ５−ａで必要なバッファ２のサイズ
を計算し、バッファ管理モジュール８にステップ５−ｂ
でバッファ獲得を要求する。図７において、バッファ管
理モジュール８のバッファ獲得処理ルーチン９では、ま
ず、ステップ８−ａで要求を出した受信タスク５のＴＣ
Ｂ６を調べ、また、ステップ８−ｂとしてその時点での
当該受信タスク５のタスク使用バッファ量６−ａと、新
たに要求されたバッファ２の大きさを加えた値が、各通
信リンク４毎に決められている使用上限値を超えるかど
うかを調べる。超える場合にはステップ８−ｃでバッフ
ァ２を割り付けず、通信リンク４毎のバッファ枯渇状態
発生を要求元である受信タスク５に通知する。また、こ
の上限値を超えない場合、ステップ８−ｄでＢＣＢ１０
にある通信バッファ１全体の残存バッファ領域の大きさ
１０−ａを計算する。そしてステップ８−ｅで新たに要
求されたバッファ２の大きさを引いた値が予め決められ
ている総バッファ残量下限値よりも小さくなるかどうか
を調べる。この下限値を下回る場合、ステップ８−ｆで
バッファ２を割り付けず、システム全体のバッファ枯渇
状態発生を要求元である受信タスク５に通知する。

【００１２】これらの何れの場合にも該当しない場合、
ステップ８−ｇでバッファ獲得処理ルーチン９は通信バ
ッファ全体１の未使用メモリ領域から必要な大きさのメ
モリ領域を切り出し割り付けてこれを一つのバッファ２
とし、当該バッファ２のヘッダ部分に当該バッファ２全
体の大きさ２−ａと、当該バッファ２を獲得した受信タ
スク５のＴＣＢ６のアドレス２−ｂと、解放するための
バッファ解放処理ルーチン１１のアドレス２−ｃを書き
込む。次に８−ｈで当該バッファ２を獲得した受信タス
ク５のＴＣＢ６に記録されている当該受信タスク５のタ
スク使用バッファ量６−ａに、割り当てた当該バッファ
２の大きさ２−ａを加えた値を新たな当該受信タスク使
用バッファ量６−ａとしてＴＣＢ６に記録する。ステッ
プ８−ｉでＢＣＢ１０に記録されている通信バッファ残
存量１０−ａから、割り当てた当該バッファ２の大きさ
２−ａを引いた値を新たな通信バッファ残存量１０−ａ
としてＢＣＢ１０に記録する。

【００１３】バッファ２の獲得に成功した受信タスク５
は、ステップ５−ｅでデータ受信処理を遂行し、これを
獲得したバッファ２に記録してプロトコル処理タスク１
２に渡した後、次の通信データを受信するため一時ディ
スパッチャ３に制御を戻す。バッファ２の獲得に失敗し
た受信タスク５は後の処理を停止し、ステップ５−ｆで
獲得の失敗原因が各通信リンク４毎のバッファ使用量超
過であれば自分に割り当てられたＴＣＢ６を個別ＳＵＳ
ＰＥＮＤＥＤキュー１３にキューイングする。また、シ
ステム全体の空きバッファ残量不足であれば、ステップ
５−ｇで全体ＳＵＳＰＥＮＤＥＤキュー１４にキューイ
ングする。この後受信タスク５は制御をディスパッチャ
３に返すが、受信タスク５は対応するＴＣＢ６が個別Ｓ
ＵＳＰＥＮＤＥＤキュー１３または全体ＳＵＳＰＥＮＤ
ＥＤキュー１４から取り出され、ＲＥＡＤＹキュー７に
キューイングされるまでデイスパッチャ３から制御を渡
されない。この間、当該受信タスク５に対応する通信リ
ンク４に対する受信処理は行なわれないので、当該通信
リンク４からの通信データ流入は抑制される。

【００１４】プロトコル処理タスク１２に渡されたバッ
ファ２は必要なプロトコル処理の後、最終的には送信処
理タスク１５に渡され、保持している通信データを送信
用通信リンク１６を通して通信制御システム外部に送信
した後に不要となるか、或はプロトコル処理上の理由で
プロトコル処理タスク１２に於て不要となる。これらの
タスクは不要になったバッファ２を解放するためにバッ
ファ管理モジュール８に引き渡す。

【００１５】バッファ管理モジュール８のバッファ解放
処理ルーチン１１では図８のステップ１１−ａで解放さ
れるバッファ２を通信バッファ全体１に戻して再使用可
能にする。同時に当該バッファヘッダに記録されている
当該バッファ２全体の大きさと、当該バッファ２を獲得
した受信タスク５のＴＣＢ６アドレスに基づき、上記Ｔ
ＣＢ６に記録されている受信タスク５の使用バッファ量
６−ａから当該バッファ２の大きさ２−ａを引いた値を
新たな受信タスク５の使用バッファ量６−ａとしてＴＣ
Ｂ６に記録する。この結果、ステップ１１−ｂでＴＣＢ
６に記録された当該受信タスク５の使用バッファ量６−
ａが予め各通信リンク４毎に決められている使用上限値
を下回り、かつその時点で当該受信タスク５に対応する
ＴＣＢ６が個別ＳＵＳＰＥＮＤＥＤキュー１３にキュー
イングされているかを判定する。もしそうであれば、ス
テップ１１−ｃで当該ＴＣＢ６を個別ＳＵＳＰＥＮＤＥ
Ｄキュー１３から取りだし、ＲＥＡＤＹキュー７にエン
キューし直す。次にステップ１１−ｄでＢＣＢ１０に記
録されている通信バッファ全体の残存バッファの大きさ
１０−ａに当該バッファ２の大きさ２−ａを加えた値を
新たな通信バッファ全体１の残り空きバッファ領域の大
きさ１０−ａとしてＢＣＢ１０に記録する。ステップ１
１−ｅでＢＣＢ１０に記録されている通信バッファ１全
体の残存バッファの大きさ１０−ａが予め決められてい
る総バッファ残量上限値を超え、かつその時点で全体Ｓ
ＵＳＰＥＮＤＥＤキュー１４にキューイングされている
ＴＣＢ６が存在するかを判定する。もしそうであれば、
ステップ１１−ｆでこれらのＴＣＢ６を全体ＳＵＳＰＥ
ＮＤＥＤキュー１４から取りだし、ＲＥＡＤＹキュー７
にエンキューし直す。

【００１６】この後、プロトコル処理タスク１２、或は
送信処理タスク１５における処理終了に伴い制御がディ
スパッチャ３に戻されると、図５のステップ３−ｄでデ
ィスパッチャ３は再度ＲＥＡＤＹキュー７を調べ、ステ
ップ３−ｃでキューイングされているＴＣＢ６があれば
一つづつ取り出して逐次制御を渡し受信処理を再開させ
る。このようにして、通信制御システムのバッファ使用
状況を設定上限及び下限値と比較して監視してバッファ
の割り付け使用・停止・再開をするので、通信処理自体
は継続ができる。通信制御のデータは一般のデータ処理
とは異なりデータの処理速度が遅く、また一定のフロー
制御が必要である。またデータの再送がシステムとして
認められているので、バッファ管理手段が入口の受信タ
スクでのデータの流入を抑えて一元的にバッファの使用
を制限しても何らさしつかえない。これらの事情が上記
構成を可能にした大きな理由である。

【００１７】実施例２．実施例１では各受信タスクを平
等に扱っていた。本実施例ではこれに優先度を取り入
れ、例えば優先度１の受信タスクは無条件に共通の通信
バッファ１の残存バッファを割りつけられ、優先度２の
タスクは実施例１と同じ条件で残存バッファの割り付け
を受けるとする。この場合には図３のＴＣＢには６−ｂ
の処理優先度レベルの欄を設ける。その動作としては以
下のようになる。バッファ管理モジュール８は、図７の
ステップ８−ｂで使用量超過を調べる際、ＴＣＢの優先
度レベルを参照する。そして優先度レベル１であれば無
条件にＮｏとする。すなわち通信バッファ１が確保され
てしまう。これ以降の動作は実施例１と同様である。更
に優先度を複数に分け、一方、バッファ獲得処理ルーチ
ン９でも個別の使用量上限値と、全通信バッファ残存量
に対する設定下限値を対応して複数レベル設けるように
してもよい。

【００１８】実施例３．実施例１では通信バッファの割
り付けに過去の受信タスクが行った処理データは考慮さ
れていなかった。これを受信量が多い時にはそれぞれの
受付処理量を減らして受信サービスを平等にすることを
考える。すなわち図４のＢＣＢに、１０−ｂとして過去
一定時間の使用バッファ量の記録領域を設けておく。そ
の動作は以下のようになる。バッファ管理モジュール８
は、図７のステップ８−ｂで個別の使用量超過を調べる
際、及び８−ｅで通信バッファの残存量を調べる際、Ｂ
ＣＢの過去の使用バッファ量１０−ｂを参照してＹｅｓ
−Ｎｏを決める。例えば受信が多い場合は受信が少ない
場合の１／２の上限値以下で個別の使用量が超過である
と判断する。また通信バッファ全体１の残存バッファ量
を調べるステップ８−ｅにおいても、受信が多い場合は
余裕のある内にＲＥＡＤＹキューの処理ができるよう比
較基準の下限値を動かす。これらの動作が実施例１、実
施例２同様にオペレーティング・システムの助けなしに
実行できる。なおこの実施例は上記実施例２と組み合わ
せることも可能である。

【００１９】実施例４．請求項４の発明の通信バッファ
管理装置の実施例を説明する。本実施例では、共通の通
信バッファ１からの各受信タスク対応のバッファ２の切
り出し割り付けに関連して、万一バッファ処理で不具合
が生じた場合に、解放処理ルーチンのアドレス不正によ
って処理が中断し、障害解析ができるようにしておく。
即ち、バッファ管理モジュール８はバッファ２獲得時に
は個々のバッファヘッダに当該バッファ２のバッファ解
放処理ルーチン１１アドレスをセットする。このバッフ
ァ２を解放する際には解放するタスクがバッファヘッダ
からこの解放処理ルーチンアドレスを取りだしてこのバ
ッファ解放処理ルーチン１１を呼び出す。解放処理ルー
チンアドレスの格納場所２−ｃは、各バッファ２の先頭
から固定のオフセットを足した部分にセットされること
になっているので、バッファ２のアドレスが決れば単純
計算によって求めることができる。

【００２０】動作は以下の通りである。解放しようとし
たバッファ２のアドレスが正しく、かつバッファ解放処
理ルーチン１１のアドレスが破壊されずに保存されてい
た場合は、バッファ管理モジュール８のバッファ解放処
理ルーチン１１によるバッファ解放処理が正常に行なわ
れて、バッファヘッダの内容は全て無効化（０にセッ
ト）される。通信制御システムの不具合により、各タス
クが解放しようとして指定するバッファ２のアドレスが
誤っていたり、バッファ２のアドレスは正しいがバッフ
ァ２の使用に誤りがあったためにバッファヘッダの内容
が破壊されていた場合、バッファ解放を行なおうとする
タスクが呼び出す解放処理ルーチン１１のアドレスは不
正なアドレスをさす事になる。この結果、バッファ解放
処理ルーチン１１呼び出しの瞬間に「マシン命令例
外」、「メモリ保護違反」、「アドレス例外」等の実行
違反が発生（これは既にプログラマブルな一般の計算機
において広く実用化されている技術を流用している）
し、通信制御システムの処理が中断される。このように
して不具合による障害発生が発生し、バッファ管理が不
正になった時点で即座に通信制御システムの処理が中断
される為、障害発生に至る経緯を知るための情報が失わ
れずに残り、不具合の原因を解析することが容易とな
る。

【００２１】

【発明の効果】以上のようにこの発明によれば、バッフ
ァ残存量テーブルと、タスク使用バッファ量テーブルと
を備え、残存バッファ量が所定下限値以下か使用タスク
バッファ量が所定上限値以上でバッファの割り付けを停
止し、元に戻ると割り付けを再開するようにしたので、
通信リンクに対するサービスを公平にし、またたとえ一
時処理が停止されても、再開を容易にする効果がある。
請求項２の発明によれば、更にタスクの優先度に応じて
処理順序を変更でき、きめ細かいサービスが可能になる
効果がある。請求項３の発明によれば、バッファ管理モ
ジュールがバッファの割り付け・解放を行うので、サー
ビスの内容変更が容易で誤りが少ないという効果があ
る。請求項４の発明によれば、バッファ処理に不具合が
生じても、トレース結果から容易に内容を知ることがで
きる効果がある。

【図面の簡単な説明】

【図１】この発明の一実施例である通信バッファ管理装
置の構成を示すブロック図である。

【図２】この発明の一実施例でのバッファの構造を示す
ブロック図である。

【図３】この発明の一実施例でのタスク使用バッファ量
を記憶するＴＣＢの構造を示すブロック図である。

【図４】この発明の一実施例での利用可能な総残存バッ
ファ量を記憶するＢＣＢの構造を示すブロック図であ
る。

【図５】この発明の一実施例におけるディスパッチャの
処理を示す流れ図である。

【図６】この発明の一実施例における受信タスクの処理
を示す流れ図である。

【図７】この発明の一実施例におけるバッファ獲得処理
ルーチンの処理を示す流れ図である。

【図８】この発明の一実施例におけるバッファ解放処理
ルーチンの処理を示す流れ図である。

【符号の説明】

１ 通信バッファ ２ バッファ ２−ｃ 解放処理ルーチンアドレス ３ ディスパッチャ ５ 受信タスク ６ ＴＣＢ ６−ａ タスク使用バッファ量テーブル ６−ｂ 処理優先度レベルテーブル ７ ＲＥＡＤＹキュー ８ バッファ管理モジュール ８−ｂ タスク使用バッファ量と設定上限値との比較ス
テップ ８−ｅ 通信バッファ残存量と設定下限値との比較ステ
ップ ９ バッファ獲得処理ルーチン １０ ＢＣＢ １０−ａ 通信バッファ残存量テーブル １０−ｂ 過去一定時間使用バッファ量テーブル １１ バッファ解放処理ルーチン １２ プロトコル処理タスク １３ 個別ＳＵＳＰＥＮＤＥＤキュー １４ 全体ＳＵＳＰＥＮＤＥＤキュー １５ 送信処理タスク

Claims (4)

【特許請求の範囲】
1. 【請求項１】 利用可能な残存バッファ量を記憶するバ
   ッファ残存量テーブルと、 上記残存バッファ量から各タスク毎に割りつけられるタ
   スク使用バッファ量を記憶するタスク使用バッファ量テ
   ーブルとを備え、 上記残存バッファ量が所定の下限値より小さくなるかま
   たはタスクで使用するバッファ量が別の設定上限値より
   も大きくなる場合は、上記残存バッファの使用を停止し
   て要求元のタスクに通知し、上記残存バッファ量が所定
   の下限値より大きくなりかつ各タスクで使用するバッフ
   ァ量が別の設定上限値よりも小さくなると、残存バッフ
   ァの使用を再開する通信バッファ管理装置。
2. 【請求項２】 各タスクには処理優先度を設定し、タス
   ク使用バッファ量テーブルは優先度も含めて記憶し、残
   存バッファの使用を停止または再開する際に上記優先度
   も参照して決定することを特徴とする請求項１記載の通
   信バッファ管理装置。
3. 【請求項３】 各タスクが使用するバッファには、使用
   バッファサイズとタスクリンク情報とを記載し、また各
   バッファの割りつけ・解放を行うバッファ管理モジュー
   ルを備え、 残存バッファの使用が停止された場合は、対応タスクの
   リンク情報を蓄積するキュー・バッファをも備え、残存
   バッファの使用／停止／再開は上記バッファ管理モジュ
   ールとキュー・バッファを用いて行うことを特徴とする
   請求項１記載の通信バッファ管理装置。
4. 【請求項４】 各バッファの割りつけ・解放を行い、ま
   た上記バッファ解放時の処理を行う解放処理ルーチンを
   持つバッファ管理モジュールを備え、 各タスクが使用するバッファには、当該使用バッファを
   解放する上記解放処理ルーチンのアドレスを記憶するこ
   とを特徴とする請求項１記載の通信バッファ管理装置。