観察日記 2010-12-06

素直なスピンロックとCore i7

見直していて気づいたので備忘録として書いておこう
bug#3890だけど
{util_mput} Ruby 1.9 - Bug #3890: ビジースレッドがあるとコンテキストスイ... http://tinyurl.com/2d7reaq
これ、Core i7 なのが原因
メモリコントローラがCPUに内蔵されると、スレッド間でロックの取り合いをしたときに
最後にロックを握っていた人がほぼ確定的に勝ってしまうという問題があり
(だって、CPUトポロジ的に一番近いんだもん)
ほほう
素直なスピンロック実装は動かなくなるという罠がある
うちの古い xeon (4core x 2) でも再現していて
というか昔から困っていてやっと直したという
なんで Mutex にすると直るのか謎
ま、Windowsはもう救われたので他人事。
Windows 凄い
Mutexの中でロック順序をまもるよう待ちキューがあるだけだと思う
ですかねー
APIのなかでがんばってるだけだよねきっと。
普通にMutex作ったら、待ちスレッドをリストにつないでいくのでFIFOになりますよね
CriticalSectionは何もがんばらないものなのでまあ当然と。
CriticalSectionは普通につくるとspin lockなので、まあ、そうなるかなと
Windowsを作ってる人たちはマジだから。
glibcはあんまり気合い入ってないよね
まあそういうことだよね。
Rubyも気合入ってないね

Reviewing Ruby

rubyはコードレビューすればありえない級のうっかりバグが結構ある。trunkで変更があった行付近はとにかく私は読むからあれなんだけど、人手が欲しい。
えーと、レビュー魔の僕から言わせるとですね
99%あってて、1つだけ間違ってるパッチはレビューしやすいけど
Rubyみたいに、あやしげな行が沢山あるコードは恐怖です
変えるの怖い
全部kosakiさんに直して欲しい
それだ
KRuby
とりあえず signal は全部かきなおしたい
コードリーディング能力が低いのもあるけど、rubyのコードは難しいですorz
難しいです・・・・ > ruby
1.8あたりまでは割と簡単だったと思うけど
まだyarvとthread周りが読めてないという。ひどいコミッタ
めんどくさいところはeval.cに集中してたし
だから eval.c が読めないんだ!
linux.fmを聞いてたけど、要所要所に必要なコメントはあるのね。
コメントになるといい声になる?
なんと言っても、聞いててどんな処理が来るのか分かる。rubyではあり得ない。

opensslとかは怖いからわたしはいじらないので、レビューできる人はレビューしてやってください

parse.yが難しい

なんとびっくり
def Foo::Bar.m2
シンタックスエラーだった
def (Foo::Bar).m2
こうしないといけないらしい
うん
それは有名だと思っていた。
知らなかった
なんか意図があるのかしら
こんなところで::使うなよ! とか
parse.yが難しい
という理由ではないかと思う。
その括弧が省略できた人はMatzに同意を得る必要がないので即時で突っ込んでください。
可能なら。
まぁ、書いたこと無いな
現在のparse.yだと、singletonのところに適切なルールを追加すればこの問題が解決できる。
shift/reduceなしで? > 解決
shift/reduceなしで追加できなければ適切ではない、という意味で。
つまり俺は試したことがある :)
じゃあ入れてくださいよ
できないという結論に達したから入れてないんだよもちろん。

腕に覚えがある方はどうぞ