◆直った？平気？◆Core2Duo◆3エラッタ

超遅レスだけど誘導されて来たので
（ここから→http://pc7.2ch.net/test/read.cgi/notepc/1138747140/)

>>80
>複数のスレッドで値を更新するのにMutexかけないような馬鹿プログラム
>がどれだけあるか、だな。

馬鹿プログラムって・・・Intel の定めた IA32 のメモリモデルではメモリバリアが要らないはずの
処理で問題が起きるからこそこれがErrata AH.18としてリストアップされたわけで。

カリカリにチューンしないで何でもかんでも排他してる遅いプログラム、Itaniumでもソースコード互換を
目指してItaniumのキツいメモリモデルに準拠したソースで書いてるプログラムならエラーは出ないけど。
IA32用にカリカリに高速化されていたアプリの中にはエラー発生条件を満たしてしまうものもあると思う。

>>413
そんなプログラムはアセンブラを使うのでソース互換などありえん。

>>414
意味わからないのに、無理にレスする必要はないんですよ。

>>415
メモリバリアを意識したプログラムを書いた経験がないくせに無理するなよ。

>>1-415
◆直った？平気？◆

CPUなんかにバグなんてあるわけないだろ。
プログラムが仕込まれてるわけじゃあるまいし。

なんでもかんでもMutexすれば良い訳じゃないしな
Mutexってのは資源管理の比較的楽な方法論だが、処理的には重い。
「食事する哲学者の問題」の様な致命的な問題も原理的に内包してる。
現実問題に直せば・・・Mutexとったスレッドが別のMutex待ちでストール以下略でデットロックとか。
全てのプログラマがこれらを完全に考慮したと考える方がおかしいわけで、

そもそもIA32の規定外動作だからｴﾗｯﾀになると言うのに。

>>418
釣餌が腐ってますよっと。

実際、非同期で複数スレッドから読み書き書き込みするような変数の使い方はどう考えても問題があるよ。
書き込み順序とか保障されないじゃん。
ただ、同じ変数じゃなくとも同じキャッシュライン上の独立した変数でも理屈上起こりうるんじゃね？

変数が独立なのにキャッシュラインが共有されてるとエラッタ抜きにしても
パフォーマンス上の問題ありそうなので、各スレッドに引数として渡す個別パラメータは
__declspec( align(32) )でやってます、ええ。

どうしてmutexじゃなくspinlockの話が出ないのか・・・
みんなOSの上で行儀良く動くプログラムしか作っていないんだな。

　　　　　　　　 　 　　　　　　　,　-──‐- ､
　　　　　 　 　 　 　 　 　 　／.::::::::〈{薔}〉:::::.＼
　　　　　　　 　 　 　 　 　/.:::::;． '"´ ￣｀`ヽ､::.ヽ
　　　　　　　　　　　　 　 l ,.ィ´,　　l l| 　|l l l `ヽ:::l　　　 Conroeの圧倒的性能と安さ
　　　　　　　　　　　　 にl/コ l　」_|_||　/LLl_　l ,ﾘ　高くて低性能な高消費電力64・AM2　
　　 　 　 　 　 　 　 　 に|ｺl. |´ヽlヽll // ﾘ |/`l llﾄ､.　　　 AMDｵﾜﾀ＼(^o^)／
　　 　 　　. :. :;.:.:.ヽ 　 /　ﾄﾄ､ヽ´￣`　　´￣7 /| ∧
　　　　 .: .:.:;:.::::;:.:::::.ヽ/　 l ﾄ､＼l　　┌┐　 / //|/ ∧　　,, ,､､､.:::.,､､
　 .: .:.: :.: .:.:;:.:::.:;:;:.::.:/　 / /l. .＼ >､ _二_ イ //,⊥./ ∧ィ.: ;: ;:; :::::.:; :;. :.､､
　　'"´ .:. :;:.:::.:;:;::;:.:/　 / /.:.:::::::.ヽヽ.::::lil:::::| //.::::::::::.＼l.::;::::::::::;:;:;::::::.:. :. :. .｀ヽ
　　 .:. :　.: :;:;.:.:;:;:;/　 /ノ.:.:::::::::::::::〉 〉.:liil::::|//.::::::::::::::::::.＼;:;:::::::::.::;;:.::. ｀ `
　　　' "´ ￣｀`:/　,.ｲ.:.:::::::::::::::／ |〈 ⌒ヽ|/^ヽ:::::::::::::::::::::::〉´ ￣ ｀`
　　　　　　 　 /　/〈.:::::::::::::::::にこj ﾊ(⌒ l〈こｺ7.::::::::::::::::/ ＼
　　　　　　　/　/ / `ヾ::::::::::::::l　∧爪　 〈〈:.＼l.::::::::::::::/　　　',
　　 　 　 　 l.　l　l　l l .l::::::'"´::|/^V.:.:.`Y^ヽヽ.:.::::::｀`ヽ〉　 |　 |
　　 　 　 　 |　|　|　|　/.::::::::::::/ 　 〉　 〈　　　l乃:::::::::/1　 |　 l
　　 　 　 　 |　|　|　| 〈.:::::::::::/　　〈　 　 〉　 ,ｲノ::::l:::/　|　 |　/
　　 　 　 　 |　|　|　|　 ',:::::::::',ー‐'^ヽ　/, ｨｲ/.::::::::|/ | /　/l/
　　　　　　　ﾄ ﾄ､ ﾄ､ﾄ､/|::::::::::i ヽ　　_)ﾉノ.::i.:::::::::::::|ヽl/ l/
　　　　　 ＿　　 __＿ ノ.::::::::::Lﾉ　 /.::::::::::::|.:::::::::::/（
　,.　 '"´.:.:.::::::::::::::::::::::/ .::／.:.:〃ハ::::::::::::::|.::::::::/.::::.＼
　.:.:::::::::::::::::::::::::::::::::::/ .::/.:.:::/:/　　i:::::::::::::|.:::::/.:::::::::::::.＼

たまにはクリティカルセクションのことも思い出してあげてください。

Windowsってマルチスレッドの同期の手段はやたら充実してるよねー
排他ロックしないといけない処理の内容によって使い分けるでしょ。

ちなみにCriticalSection APIってMONITOR/MWAITを使ってくれる？
ビジーループにしなくて済むから待機中の省電力化に有効なんだけど。

windbgで見るとRtlEnterCriticalSectionはpause付きspinlockだな。

>>424
してねーよ。セマフォなんてほとんど使わないし
汎用のメッセージキューがないのが痛すぎ
わざわざ自前で作らなきゃいけない

>>426

スレッド毎にメッセージキューは存在するよ !?

GUIスレッドにはあるね。問題はGUIスレッドにしかないという点
サービスで動作するようなプログラムには使えない。
MSMQ使えばUNIXと同じようなメッセージ通信も可能だけど、
あれは元々システム間のディレイド通信用だからオーバーヘッドが
大きすぎて、トランザクション性能を気にするようなプログラムには使えない

>>426
十把一絡げで人月管理されるプログラマはそれで十分ですね。

>>420
>書き込み順序とか保障されないじゃん。

他のコアにいつ反映されるかはともかく、書いた順序で反映される（A,Bという書き込み操作が
あったとき、Bだけ反映されてAが反映されていないという事態は起きない）というのがIA32の
正しいメモリモデル　（Program Order と呼ばれる規則です）。

これじゃーキャッシュのフラッシュを頻繁にやんなきゃなんなくてキツイよね、ということで、
Itanium とか SPARC とか Java VM （の仕様）では「メモリバリア入れなきゃどーなっても知らね」に
近いメモリモデルが採用されてます。

Program Order をあてにした高速化の例としては、writerが1スレッドのリングバッファ等があります。
writerはデータを書き込んだ後でアトミックに書き込みデータポインタを更新、
reader はロック等を用いずに書き込みデータポインタを参照するだけで、読み込みポインタより
進んでいればデータを取得できる。

こういうコードでもデータが無いときは多くのプログラムでreaderはsleepなりwaitなりさせるだろうから、
結果メモリバリアが呼び出されて、多くの場合問題は起きない。writer側スレッドがデータを供給した
直後にreaderがデータを処理しようとした微妙なタイミングでのみエラーが発生することになる。

漏れ的にはすごい微妙なエラッタで・・・自分のPCならいいけど、仕事で組むシステム等では使えない
CPUだと思う。今まではIA32サーバ組むのにXeonだと高いのでPen4使う場合もあったんだけど、
そういう感じでCore2Duoを使うのは無理そう（←個人的な意見）。とても残念。

>>430
Xeonでも同じエラッタがあるのはしらんのか？

このエラッタが修正されていなければOS内で使用されている
spinlockで問題出るだろうね。

このスレ一気に過疎ったねｗ

>>431
Xeon でもダメなのか orz
spinlock 単体の動作としては（普通キャッシュラインまたがないから）問題無いような気がする。

>>432　まぁ、実害が無いに等しいからな・・・

実害はないけど、精神衛生上なんか嫌だな

それを言ったらほとんどすべてのCPUが何らかのエラッタを持ってるんだからあきらめるしかない。

問題は気にする／しないではなく実害があるかどうかだけ。

いいじゃない。動画の１コマが化けるぐらい。
誰だって気が付かないし、気づいてもオーバークロックのせいにしてしまえば。
いいじゃないエラッタ。

Intelのマニュアルにはチップに不具合が残ってる
ということしか書いてないし

心配ならメーカーにでも問い合わせればいいじゃん
BIOSにIntelが提供したパッチを適用してるのか
あるいはまだ提供されてないのか

ここにIntelの文書があるけど、
http://download.intel.com/design/mobile/SPECUPDT/31407901.pdf

AH 18 には BIOSや OS で対応できるような work around が無い。
だって単なるメモリアクセスだもの。これ全部トラップしてたら大変なことになる。
対応方法の代わりに、「ソフト書くときは〜するように。Intelは市販ソフトでこれによるエラーの
報告を受けていない」というような変なコメントがあるのみ。

既存のソフトで影響があるものは作り直す必要がある・・・・と書いていて思ったけど、
重要なソフトなら作者(等)が気使って書き直してくれるから問題ないのかな。

カーネルでもドナルドでもなんでもいいが
いまだ誰一人として、不具合発生を再現してみせた香具師がひとりもいない件

>>440
価格.comの掲示板では不具合多発してますよ

そんなのｼｽﾃﾑの不具合なのかﾕｰｻﾞｰの不手際なのかもわからんわけで
再現ﾌﾟﾛｸﾞﾗﾑまだー？（ﾊｲﾊﾟｰ兵器

>>430
あー、それそーいうアトミックなレベルじゃなくて、

複数スレッドに分けて分割処理するにしても
中間結果をマージする際に排他処理が必要でしょってこと
いずれにしてもAPIが信用できないと割とどうしようもないけど

>>439
あぁ、AH 18を言っていたのか。
それなら>>430の例では問題でないと思う。
なぜなら、
multiple agents can modify the same shared unaligned memory location at the same time
ではないから。

価格虚無って初心者ばっかりだろ。

俺はメインスレッドからワーカースレッドの状態管理変数を直接書き換えるようなこと
やってるけど、Core 2ユーザーからクラッシュだとかデータ化けだとか報告を一度も
受け取ったことがないんで、大丈夫なんでないですか。

>>440
Intelのエラッタリストは間違っていて、
実はそんなエラーは起きないんじゃないかとでも言いたいのか？

出荷時にBIOS側でパッチ当たってんじゃないかってことじゃね？

Intel「Intelコンパイラを使えば問題は出ません」
→みなIntelコンパイラを使いだす
→AMDとの性能差、更に広がる

Intelｳﾏｰのシナリオ

>>428

GUIスレッド以外にもあるよ。MSDNを読もう。

>>450
あろうが無かろうが、汎用的に使えないことに違いはないよ。
WindowsでSystemV系のIPCメッセージキューのような通信をやろうと
思ったら、イベントと共有メモリか、もしくは名前付きパイプを使って
自作するしかない

おいおい、ヨソでやってくれよ

>>451
派遣PG乙

>>448
AH.18 はBIOS直してもOS直してもだめ。
購入後インストールするソフトのうち、問題を起こしそうなものを検出して
BIOSがパッチ当ててくれるんなら別だけど。ありえないでしょ。

そういえば大昔S3のビデオカードのドライバに、32bit DMA 転送を利用する
アプリ400個くらいのEXEの名前が含まれていたことがあったっけ・・・
その名前のEXEから呼ばれたときだけ動作モードを変えてた。

やっぱり初物は見送りが賢明ですな。
ケントフィールドでは直っているんだろうか。。。