いつまでもデブと思うなよ で一世を風靡した岡田 斗司夫のオバカ本。
視点が新鮮なので、結構楽しめた。
でも調査不足が感じられるので、このネタで1年間講義とはできまい。とかおもた
まあ暇つぶしにはいい感じですよ。安いし。
あと死ね死ね団超カッコイイ!!
視点が新鮮なので、結構楽しめた。
でも調査不足が感じられるので、このネタで1年間講義とはできまい。とかおもた
まあ暇つぶしにはいい感じですよ。安いし。
あと死ね死ね団超カッコイイ!!
Becky用プラグインがあることを知ったのでGoogle Desktopをインストール。
うむうむ、いい感じ。
メールって数が増えると検索がむっさ大変になるんだよね。
ついでに、カレンダソフトやら、タスク管理やらも全部Google Desktopさんへ移す。
しばらくこれでやってみる
うむうむ、いい感じ。
メールって数が増えると検索がむっさ大変になるんだよね。
ついでに、カレンダソフトやら、タスク管理やらも全部Google Desktopさんへ移す。
しばらくこれでやってみる
最近読んだ本シリーズ
結局いいたいのは
・日本はアメリカにとって(地政学的に)超重要な同盟だからそうかんたんには、切られない。もっと無理いってもヘーキ
・自衛隊には敵国に兵力を投入する能力が徹底的に欠けているので、自力戦争は無理。だから日米同盟重要だし、ぎゃくに近隣諸国にはこの事を明確につたえて日本脅威論を排除すべき
の二点だけなのかとオモタ。
データとかがすくないので、それ以上は著者の感想にすぎず、あまり意味ないかもしれん。
いやあ、こんな素晴らしい本をタダでいただけるなんて素晴らしいですね。
ありがとうございます > 高林様、オラ入りー様
なにかhyoshiokさんの所では、若干厳しめのレビューをされてるみたい。
たぶん、NHKに取り上げられた 女子大生のブログ炎上とかの記事をみて、ベタ褒めすると炎上する日本のBLOG力学に思うところがあったに違いない。
と、無理やり時事ネタに絡ませつつ、おもしろいから、ここは一発絡んでおこう。
いやいや。
#94の例では lock_array[me] を変更するのは自分だけで、lock_array[other]を変更するのは相手だけなのでxchgは必須じゃないですよ。
(lock_array[me]を変更するのが自分だけである以上、変更直前の値はかならず自分が前回設定した値だから、チェックするまでもない)
”double checked locking”あたりで検索するといろいろと出てきますよ。
無理やり要約すると
・パターンハッチング(ジョン・ブリシデス著 ビアソン)にてdouble checked lockingパターンが紹介される
・JavaでJavaVMのメモリオーダーが原因でdouble checked lockingパターンを使うとある種のJIT VMでうまく動かない事が報告され、話題になる
・C#はvolatileにメモリオーダー的な意味を追加して、この問題を回避
・Javaもそれに追従して、volatileの意味を改定
・実は元々のC++にも同じ問題があるのだけれど、完全に置いてきぼり(n'ω'`) <--今、ここ
正味の話、たとえば、int変数1個writeするだけだと、strong memory orderだと、pthread_mutex_lockかけなくても正しいけれど、現実のプロセッサはそうではなく、かつ、そのようなメモリオーダーの話が「一般のプログラマには難しすぎるから」というよく分からない理由でmutexとかの説明にマトモに解説されていないので、似たようなバグが次々と量産されているという感じ。
オイラ、元々組み込み屋さんだから、こういうタイミング問題は何回も痛い目にあっているので。
まだ、全部読んでないのでちゃんとした書評はあとで書こうと思うけども、今回はこんなところで。
P.S.
と、ここまで書いてから#94は、double checked locking パターンを題材に書き直せば作為的度が減って、よりグッドになりそうな悪寒がしてきた。
うーん、惜しい。
↓ 初回限定カバーはこんなのらしい
ありがとうございます > 高林様、オラ入りー様
なにかhyoshiokさんの所では、若干厳しめのレビューをされてるみたい。
たぶん、NHKに取り上げられた 女子大生のブログ炎上とかの記事をみて、ベタ褒めすると炎上する日本のBLOG力学に思うところがあったに違いない。
と、無理やり時事ネタに絡ませつつ、おもしろいから、ここは一発絡んでおこう。
#94「プロセッサのメモリオーダリングに注意」の例のプログラムだが、これはメモリオーダリングの例ではなくてアトミックな交換(xchg)が出来ていない例なのではないだろうか?
いやいや。
#94の例では lock_array[me] を変更するのは自分だけで、lock_array[other]を変更するのは相手だけなのでxchgは必須じゃないですよ。
(lock_array[me]を変更するのが自分だけである以上、変更直前の値はかならず自分が前回設定した値だから、チェックするまでもない)
アプリケーションレベルでメモリオーダリングに注意しなければいけない例というのはあまり思いつかなかったのでもし適切な例があればご教示いただきたいところである。
”double checked locking”あたりで検索するといろいろと出てきますよ。
無理やり要約すると
・パターンハッチング(ジョン・ブリシデス著 ビアソン)にてdouble checked lockingパターンが紹介される
・JavaでJavaVMのメモリオーダーが原因でdouble checked lockingパターンを使うとある種のJIT VMでうまく動かない事が報告され、話題になる
・C#はvolatileにメモリオーダー的な意味を追加して、この問題を回避
・Javaもそれに追従して、volatileの意味を改定
・実は元々のC++にも同じ問題があるのだけれど、完全に置いてきぼり(n'ω'`) <--今、ここ
正味の話、たとえば、int変数1個writeするだけだと、strong memory orderだと、pthread_mutex_lockかけなくても正しいけれど、現実のプロセッサはそうではなく、かつ、そのようなメモリオーダーの話が「一般のプログラマには難しすぎるから」というよく分からない理由でmutexとかの説明にマトモに解説されていないので、似たようなバグが次々と量産されているという感じ。
オイラ、元々組み込み屋さんだから、こういうタイミング問題は何回も痛い目にあっているので。
まだ、全部読んでないのでちゃんとした書評はあとで書こうと思うけども、今回はこんなところで。
P.S.
と、ここまで書いてから#94は、double checked locking パターンを題材に書き直せば作為的度が減って、よりグッドになりそうな悪寒がしてきた。
うーん、惜しい。
↓ 初回限定カバーはこんなのらしい