« 前のひとこと | トップページ | 次のひとこと »

cocolog:89156596

ショック。ELDE (Exhaustive Lock Dependency Emulator) に大きなミスを発見。実際にはありえない「虚実行」を数え上げてた。「虚実行」群がすべてのテストに合格すればそれに含まれる「実実行」群も合格する…といった使い方ができるかもしれないが…。 (JRF 7190)

JRF 2018年4月 6日 (金)

あるプロセスで別のプロセスのアンロックロックをかけ、双方のプロセスでいくつかロックが過ぎてから、、元のプロセスへ復帰したというとき、その間のロックには必ず前後関係がなければならないが、そのような関係がない仕様も含めていたのが問題となった。

エミュレートはできるが、実際にはそういう実行はありえないということで、そういうのを「虚実行」と呼ぶことにする。対称的なものを「実実行」と呼ぶ。

ELDE ではそういう「虚実行」も普通の実行として扱っていたのだった。これは大きなミスだ。

なぜ今まで誰も指摘してくれなかったんだろう! ああ、過疎ブログの悲しさよ。

JRF2018/4/68705

……。

詳しくは↓に追記した。

《Exhaustive Lock Dependency Emulator その1 並列処理の総当り》
http://jrf.cocolog-nifty.com/software/2011/06/post-1.html

↓にも注意を書いた。

《Exhaustive Lock Dependency Emulator その2 wait_and_lock》
http://jrf.cocolog-nifty.com/software/2011/07/post.html

JRF2018/4/63927

……。

はじめは上の追記で「もっと簡単に」で説明した最初のロックと最後のロックの場合のみが問題だと思い、「左開実行」が一つで残りが「左閉実行」、「右開実行」が一つで残りが「右閉実行」のものを、「閉実行」などと呼んで、それだけ検出すればよいかと思っていて検討していたら、上の「虚実行」の一般的な問題に気付いた。

追記にも書いたように、「虚実行」か「実実行」かを判定するプログラムを書こうかと思ったが難しい。ロック仕様から完全に別物にしたほうが早いと思う。今、それを考えているところ。

JRF2018/4/68015

……。

キッカケは、複数ロックを可能にしようともくろんだことにあった。複数ロックは、単一ロックへの変換みたいなのを考えればできるかな…と長い間考えていたが、どうもダメそうなので、複数ロックそのものをやったほうがいいと思い直して…しばらくして、最近になってやっと真剣に考えはじめ、それで、過去の記事を詳しく調べているところ、この問題に気付いたのだった。

でも、過去のプログラムを実行するうちに、なんか合ってる部分はある。こう考えたのにも何らかの理由があるはず。…と信じて、なんとか「虚実行」という考え方に致ったのであった。

JRF2018/4/62087

……。

しかし、間違えていたことは認めなければならない。あちらでは書かなかったが、こちらでは素直に謝っておきたい。

申し訳ありませんでした。

JRF2018/4/65834

« 前のひとこと | トップページ | 次のひとこと »

トラックバック


トラックバックのポリシー

他サイトなどからこの記事に自薦された関連記事(トラックバック)の一覧です。

» cocolog:89185782 from JRF のひとこと

組み合わせと順列の数え上げのアルゴリズムの Python のソースを Perl に書き換えた。効率的なアルゴリズムが日本語での紹介がググってもなかったので、一応、ブログ記事にしておいた。 続きを読む

受信: 2018-06-29 14:35:53 (JST)