mishimaの日記: リソースとロック 1
しばらく見ない間に日記も様変わりしてるね。
新しい言語を仕事でC++を書いてる間に妄想した。
自分としてはこんな感じのコードが書きたいわけ。
wopen( "/hoge/file" ) {
// ファイルオープンに成功した場合
print "デフォルトの出力ストリームへ書き込み。";
print "wopen(){ } の中ではそこでオープンしたファイルが標準出力ストリーム。"
print "つまり /hoge/file に書き込まれる";
}
or {
// 失敗した場合
}
ファイル記述子とかの、利用開始したら終了処理をすべきリソースを
{ } で管理するのはほとんどの場合で便利だと思う。
もちろん、明示的に管理もできるべきだけど。
問題は、マルチスレッドでのロックの問題だ。
Java のようなブロック単位での競合管理はあまりよろしくない、という話がある。
synchronized( A ){
// 処理
}
// ここで B の状態変更されると困る!
synchronized( B ){
// 処理
}
とかね。そしてこれは実際は良く起こる、とか。
いや、ロック以外の手法をとるべきかもしれない。
ロックは競合を避けるための「手段」であって「目的」ではない。
関数自体に「この関数はこの共有リソースを使うよ」と宣言させる、
とかの方法でもいいかも(それでうまくいくのかどうかは分からんが)。
基本的に、ロックの粒度は大きい方が良いと思うが、どうか。
大きなロックはロッキングが頻繁に発生するため効率が良くないのは仕方がないが、
小さなロックではプログラマがロックを管理できなくなる。
ロックを管理できないということはデッドロックしうるということで、
これはスピードの低下などよりずっと致命的だ。
ロックといえば、問題はそれにとどまらず、
「スレッド間での競合を防ぐ」のか「プロセス間での競合を防ぐ」のか
「ホスト間での競合を防ぐ」のかという問題もある。
むむ。
今妄想してるのは
「ネットワークで別サーバにオブジェクトとスレッドを移すことができるスクリプト言語」
だったりする。
そうすると、現在使われているサーバ自体に問題があった場合、
別サーバを立てて全オブジェクト(含む全スレッド)を別サーバに移動させれば
処理を中断させることなくサーバ移行ができるということなんだけども。
そうそう、
やはりC++のいいところは演算子の多重定義とデストラクタだと思う。
自分が良くやるのは
try{
File f("hoge.txt"); // ファイルのオープン
...
// f はブロックを抜けるとクローズされる
}
catch( const std::exception& e ){
}
こういう、ブロック単位でリソースの共有をしたい状況は結構多いと思う。
それで先ほどのような書き方をしたいという話になったが、
まあ「ブロック演算子」なるものを導入、とかで対応できるだろう。
さらに言えば、正規表現と拡張BNFをスクリプト言語に組み込んで、
言語仕様そのものを拡張可能に…取り止めがなくなってきた。
Pythonはいかが?とか言ってみるテスト (スコア:2)
スクリプトって言うなら、Pythonを弄ってみると面白いかもしれません。
動きはともかく、例の{}が無くてネストでブロック定義ってのが肌に合うかどうかが問題かもしれませんが。あのへんは、慣れの問題ですけど(汗