gm300の日記: なんか
日記 by
gm300
DNSを引くのが遅い。firefox遅い。
thread bzip2、圧縮のほうは複数 file の連続圧縮の部分で dead lock していたが修正。28K 回連続して圧縮したがlockしないのできっと大丈夫なんだろう。
この何回も同じ操作してもOKだからOKだという理論は久しぶりだ。大昔はそんな時もあったが、single thread の普通のbugの場合、同じマシンで同じデータを繰り返し処理してもほとんど確認の意味がない。が、しょうがないので試していた時代もあった。その後memory debugger のおかげで状態は大きく変わった。以前なら、実戦投入までは数ヵ月慣らしをおこなったような大胆な操作を行うプログラムでも今なら数日だ。
しかし thread はまだまだだ。valgrind の場合、thread はシリアル化されてしまうので同期pointを挟まないraceは見えない。まあ、見えてもなんだかわからんというのが感想だが。
そこで同じデータをずっと流すという作戦になる。同じデータでも結構わかる。今朝10時ころの状態では1000回に一回くらいlockしていた。2000回の試行で起こる可能性が 0.99999 の現象が2000x14回起こらない確率は無視できるくらい低いな。確率0.001 の現象が1000回連続で起こらないのと28K回起こらないのを比較するとたいしたことないな。
thread bzip2、圧縮のほうは複数 file の連続圧縮の部分で dead lock していたが修正。28K 回連続して圧縮したがlockしないのできっと大丈夫なんだろう。
この何回も同じ操作してもOKだからOKだという理論は久しぶりだ。大昔はそんな時もあったが、single thread の普通のbugの場合、同じマシンで同じデータを繰り返し処理してもほとんど確認の意味がない。が、しょうがないので試していた時代もあった。その後memory debugger のおかげで状態は大きく変わった。以前なら、実戦投入までは数ヵ月慣らしをおこなったような大胆な操作を行うプログラムでも今なら数日だ。
しかし thread はまだまだだ。valgrind の場合、thread はシリアル化されてしまうので同期pointを挟まないraceは見えない。まあ、見えてもなんだかわからんというのが感想だが。
そこで同じデータをずっと流すという作戦になる。同じデータでも結構わかる。今朝10時ころの状態では1000回に一回くらいlockしていた。2000回の試行で起こる可能性が 0.99999 の現象が2000x14回起こらない確率は無視できるくらい低いな。確率0.001 の現象が1000回連続で起こらないのと28K回起こらないのを比較するとたいしたことないな。
なんか More ログイン