[Q]:Open-VMS でのプロセス制御
Akira Fujiwara
どなたか、VAX とは ちょっと違うんですが（ほぼ＝）Open-VMSでの
プロセスコントロールについて教えて下さい。
実は、Open-VMS Ver7.1ですが、セマフォ機能やキュー機能から作成し
システムを作成していますが、プロセスのディスパッチを一時的に停止
させるようなシステムコールはあるでしょうか？
セマフォは、VMSのロックマネージャーを利用して作成しましたが
プライオリティｉｎバージョンで悩んでいます。
ロックマネージャーのＡＳＴも利用できそうなんですが、、、いまいち
目的にかないそうもありません。
どなたか、お知恵をお貸しください。
--
□■ Akira Fujiwara
■□ <fuji...@mdcnet.co.jp>
Mitsuhiro TAKEHISA
OpenVMS では、特定のプロセスを、ほかのプロセスが、一時停止させることがで
きます。
一時停止したプロセスは処理が止まります。 もちろん そこから再開もできま
す。
その方法は２つあり、
ハイバー ネーションという方法 （ この方法は sys$hiber( ) を使用し、停止
した状態を
ハイバーネーション状態といいます。 ）と、
サスペンド／リジュームという方法 （ この方法は sys$suspend( ) を使用し、
停止した
状態をサスペンド状態といいます。 ）です。
上の方法は、ほかのプロセスから一時停止させられる方法ですが、
自発的に一時停止させるときは lib$sleep( ) も よく使用します。
なお、上記システム サービス（OpenVMS が用意しているサブルーチンのこと）
の
名前は手元にマニュアルがないため多少違うかもしれません。
Ishikawa,Chiaki,remove No Spam from the address
fj.sys.vax に記事があるのをみるのは久しぶりで、のぞいてみました。
全然回答になっていないのですが、
結局、一番プライオリティが低い C が 同期用のセマフォを
獲得しているために、それに対して P 操作をしようとした
高いプライオリティのプロセス(タスク）A がブロックされてしまい
走れないというのは、いわゆる
priority inversion
という問題ですね。
リアルタイムシステムの方では問題になっていていろいろな対策が練られてい
るようです。たとえば、上のような状況では一時的に C のプライオリティをA
と同じまでに引き上げることで、より早く V 操作でセマフォを解放して(C は
その時点でプライオリティを下げる）、A が実行できるようにする
priority-inheritance （でしたか。うろおぼえ）の機構とかが提案されてい
ます。
先日といってもかなり前になりましたが、 火星探査機のローバーを制御する
ステーション（というのか、一緒に着陸した本体側）のソフトが最初の日にエ
ラーをおこしたのも、同じ priority inversion で一時的に高いプライオリティ
のタスクが実行されなかったためで、同期操作で priority inheritance を
enable にして問題をなくしたことが報告されていました。
OpenVMS にそのような機能があればいいのですが。。。
石川
--
Ishikawa, Chiaki ishi...@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki....@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
Akira Fujiwara
>
>リアルタイムシステムの方では問題になっていていろいろな対策が練られてい
>るようです。たとえば、上のような状況では一時的に C のプライオリティをA
>と同じまでに引き上げることで、より早く V 操作でセマフォを解放して(C は
>その時点でプライオリティを下げる）、A が実行できるようにする
>priority-inheritance （でしたか。うろおぼえ）の機構とかが提案されてい
>ます。
>OpenVMS にそのような機能があればいいのですが。。。
>
石川さん、こんちは。
そうなんですよ、、(+_+)
そんでもって、 OpenVMS の Lock-MGR では、いろいろ高機能そうなんですが
以下みたいのはできるのかしら？
ast_log = 0;
/* AST ルーチン（割り込みモジュールみたいなもの） */
ast_proc(){
ast_log = 1; /* フラグをＯＮとし */
sys$getlki() /* ブロックされたプロセスを求め */
sys$getjpi() /* そのプロセスの優先度を知り */
sys$setpri(0,0,PRI,0,0,0);/* そのプロセスまで自プロセスの優先度 */
/* を上げる */
sys$??????() /* ASTルーチンを再登録する */
}
main(){
:
sys$setpri(0,0,20,0,0,0);
:
ast_log = 0;
/* Ｐ操作（with AST登録） */
sys$enqw(0,LCK$K_EXMODE,&lksb,0,&name,0,
0,0,ast_proc,0,0);
:
/* Ｖ操作 */
sys$deq(lksb[1],0,0,0)
/* AST の実行フラグがＯＮだったら inheritance が */
/* 実行され優先度があげられているので下げる */
if (ast_log)
sys$setpri(0,0,20,0,0,0);
:
}
Ｑ１：sys$getlkiw() の使い方がよくわからない。
だいたい AST ルーチンのなかで sys$getlkiがWAITモード
で使えるンかしら？(sys$getlkiW)
もう、ぶつぶつ
Ｑ２：たしか VMSのASTって一度しか有効でないので、再登録
sys$??????部、はどうしたらいいのか？？？
--
□■ Akira Fujiwara
■□ <fuji...@mdcnet.co.jp>
Mitsuhiro TAKEHISA
A1: AST ルーチンのなかでも sys$getlkiw( ) は使えます。 ただし、イベントフラグは別の番号を指定してくだ
さい。
Q2: （以下参照）
A2: main( ) の AST 登録と おなじことを そのまま AST ルーチン内で おこなえばいいです。 そのときイベント
フラグは 別の番号を指定してください。
Akira Fujiwara wrote:省略
Kazuaki Matsumoto
指摘願います。
uniプロセッサマシンが前提です。
先述された
プロセスＡ（優先度高２０）
プロセスＢ（優先度中１８）
プロセスＣ（優先度低１６）
というプロセス構成でプロセスＣにブロッキングASTを登録したとしても、プロセス
Ｂ実行中にプロセスＡ
ディスパッチ->Ｐ操作となった場合は、やはりプロセスＢが走り切ってしまうので
はないでしょうか。
（ASTルーチンへもそのプロセスのプライオリティが採用されるのでは？）
素人考えながら次の手順はどうでしょうか
１．プロセスＡ側がブロッキングAST付きのロックを獲得し、そのままで通常処理を
行わせる
２．プロセスＡのブロッキングASTが呼ばれた（プロセスＣがP操作した）時点で、
自分自身が排他領域に
無いならばロックを解放してやる
３．プロセスＡが排他領域に入ろうとした時点でプロセスＣがロック獲得状態だっ
たならば、プロセスＣの
プライオリティを自分自身と同じ値に上げてやる
（この場合プロセスＡがロックを取り戻した際に元のプライオリティに戻す）
ただこれだとプロセスＣがＰ操作を行う度にプロセスＡのブロッキングASTが処理
されなければなりま
せん。
オーバーヘッドという観点では、単純にプロセスＣが排他を獲得したら無条件に
プライオリティを上げて
しまうのが良いのかも知れませんが．．．
プロセスの優先度を厳密に守る必要があるのならば、こういったオーバーヘッド
もやむをえないかと思
います。
私自身決して詳しいわけでは無いので、解決の参考までに
Akira Fujiwara <fuji...@mdcnet.co.jp> wrote in article
<6vktm0$msv$1...@mdcsv.mdcnet.co.jp>...
Akira Fujiwara
フォローありがとうございます。
In article <01bdf68c$2d451b80$0801...@osaru01.cht.co.jp>, mat...@cht.co.jp says...
>
> まじめまして、松本と申します。NGへの投稿は不慣れなもので、無礼があればご
>指摘願います。
>
> uniプロセッサマシンが前提です。
そうですね。
> 先述された
> プロセスＡ（優先度高２０）
> プロセスＢ（優先度中１８）
> プロセスＣ（優先度低１６）
>というプロセス構成でプロセスＣにブロッキングASTを登録したとしても、プロセス
>Ｂ実行中にプロセスＡ
>ディスパッチ->Ｐ操作となった場合は、やはりプロセスＢが走り切ってしまうので
>はないでしょうか。
>（ASTルーチンへもそのプロセスのプライオリティが採用されるのでは？）
ASTの実行中は、登録プロセスの環境で走りますが、プライオリティは、別みたいです。
^^^^^^
>
> 素人考えながら次の手順はどうでしょうか
>１．プロセスＡ側がブロッキングAST付きのロックを獲得し、そのままで通常処理を
>行わせる
>２．プロセスＡのブロッキングASTが呼ばれた（プロセスＣがP操作した）時点で、
>自分自身が排他領域に
> 無いならばロックを解放してやる
1.2.のケースはプロセスＡのＰ操作がネストしており、２件目のリソースでWAITし
プロセスＣがＰ操作したときに発生するでしょうが、このケースでは
“Priority Inversion”は発生しないでしょう。
>３．プロセスＡが排他領域に入ろうとした時点でプロセスＣがロック獲得状態だっ
>たならば、プロセスＣの
> プライオリティを自分自身と同じ値に上げてやる
> （この場合プロセスＡがロックを取り戻した際に元のプライオリティに戻す）
そうですね、これはいいですね、但し、プロセスＣのプライオリティを戻すのは
プロセスＣが該当リソースのＶ操作をした直後がいいですが、、、
> ただこれだとプロセスＣがＰ操作を行う度にプロセスＡのブロッキングASTが処理
>されなければなりま
>せん。
> オーバーヘッドという観点では、単純にプロセスＣが排他を獲得したら無条件に
>プライオリティを上げて
>しまうのが良いのかも知れませんが．．．
> プロセスの優先度を厳密に守る必要があるのならば、こういったオーバーヘッド
>もやむをえないかと思
>います。
>
>
> 私自身決して詳しいわけでは無いので、解決の参考までに
>
thanks!
葉っぱを見ていると森がみえないので、気分を換えて、そもそもの発生原因
から考えてみます。
--
□■ Akira Fujiwara
■□ <fuji...@mdcnet.co.jp>