革命の日々！ gcc 4.7 だとカーネルがまともに動かないんじゃないの？という話
Jan Karaがなかなか素敵なバグを報告している。 bitfieldいじるときに、64bit load/store使えうように、となりのbitfieldも合わせて read-modify-write するから全然関係ないフィールド更新時に別のフィールドがlostするって・・・ でいつものようにGCC界隈から「Cの規格書にはやっちゃダメとは書いてない」という声が飛んできて カーネル界隈から「そんなんソフトが書けるか。あほー」という怒号が飛び交う展開に だって、普通たまたま隣り合ってるだけの全然関係ないフィールドってロックも別だよねえ(-_-;) From: Jan Kara jack@suse.cz vger.kernel.org To: LKML Cc: linux-ia64@vger.kernel.org, Linus Torvalds , dsterba@suse.cz, ptesa
革命の日々！ glibcのpthread_cancel()はC++と一緒に使うと予想外の動きをする事がある
http://udrepper.livejournal.com/21541.html Ulrichがpthread_cancel()とC++は混ぜるなキケンになってるけど、オレは正しいんだ正しいんだ正しいんだ。 という趣旨のブログを書いております。 以下いつものように（主に笑いをとるための）超訳。正確な情報が欲しい人は元URLを読んでくださいませ。 #include <cstdlib> #include <iostream> #include <pthread.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static pthread_cond_t c = PTHREAD_COND_INITIALIZER; static void *tf (void *) { try { ::pthread_mutex_lock(&m);
革命の日々！ prefetch
Intel CPU の hardware prefetch はストライド付きメモリアクセスをストリームと認識できるだけのはずなので、RDBMS やガベコレのようにメモリアクセスがほとんど予測不能なものや、「フィボナッチ数列でインデックスアクセス」のようなロジックはあるものの CPU に判定不能なものは、software pfetch が利き続けると思います。 ただ昨今は hardware pfetch がストリームとして認識できる本数がどんどん増えています(Core 系はメモリ→キャッシュで12ストリーム)ので、メモリアクセスパターンが異なる複数のスレッドで hardware pfetch が混乱するから software prefetch を書くというのはなくなっていくのかも知れません。 それに Intel x86-64 CPU の Out-Of-Order 実行機能はデタラメに強化され
革命の日々！ ハチクロはUnicodeの歴史を変えてしまったらしい
togetterで「ISO/IEC JTC 1/SC 2/WG 2 ad hoc meetings: Emojiに関するTweets」がまとめられているようだ。 すばらしい。 → http://togetter.com/li/15979 と http://togetter.com/li/16108 一番面白かったのは「勝ち誇り」フェイス変更のくだりで この頭の左側のような「はぁ？なにこの鼻提灯」といった図面から 以下のような正しい鼻息に変更されたのだが そのときに使われた、日本のマンガ文化の文脈で「勝ち誇り」がどのように抽象化されているのか という説明に使われたのが以下のコマだという 小形さんの多大なる貢献に経緯を表しつつ。そして同時に、森田先輩あなたって人は・・・・
革命の日々！ Binary Hacks献本していただきました
いやあ、こんな素晴らしい本をタダでいただけるなんて素晴らしいですね。 ありがとうございます ＞ 高林様、オラ入りー様 なにかhyoshiokさんの所では、若干厳しめのレビューをされてるみたい。 たぶん、NHKに取り上げられた 女子大生のブログ炎上とかの記事をみて、ベタ褒めすると炎上する日本のBLOG力学に思うところがあったに違いない。 と、無理やり時事ネタに絡ませつつ、おもしろいから、ここは一発絡んでおこう。 #94「プロセッサのメモリオーダリングに注意」の例のプログラムだが、これはメモリオーダリングの例ではなくてアトミックな交換(xchg)が出来ていない例なのではないだろうか？ いやいや。 #94の例では lock_array[me] を変更するのは自分だけで、lock_array[other]を変更するのは相手だけなのでxchgは必須じゃないですよ。 （lock_array[me]を変
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
革命の日々！ 2.6.29で siginfo構造体のsi_pid の扱いが変わりました
