マルチスレッドプログラミング相談室 その8

1 名前：デフォルトの名無しさん mailto:sage [2009/09/21(月) 17:19:27 ] マルチスレッドプログラミングについて語るスレ ■前スレ マルチスレッドプログラミング相談室 その７ pc12.2ch.net/test/read.cgi/tech/1215253576/ ■過去スレ その１ ttp://pc3.2ch.net/tech/kako/997/997345868.html その２ ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/ その３ ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/ その４ ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/ その５ ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/ その６ ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/ OS・言語・環境は問わないが、それゆえ明記すべし。 テンプレ 【ＯＳ】 【言語】 【実行環境】 【その他特記する事項】 631 名前：デフォルトの名無しさん mailto:sage [2011/06/28(火) 21:36:49.16 ] メモリ空間が共通なのはメリットだろう常考 632 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 10:48:43.16 ] プログラムは常に死ぬ可能性がある という前提に立つと、 メモリ空間の共有はデメリットだよな 633 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 11:36:26.30 ] メリットもデメリットもある 634 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 11:51:59.86 ] >>632 >プログラムは常に死ぬ可能性がある という前提に立つと、 なんという時代遅れのやつ 635 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 12:05:00.86 ] スレッド蹴るかプロセス上げるかは、利用場面での損得勘定で決まることだから、 状況想定もなしにメリットデメリットを語ってもナンセンスすぎてなあ… 636 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 12:54:18.84 ] >>635 マルチスレッドで得られるメリットは基本的にパフォーマンスのみ。 マルチプロセスで得られるメリットはマルチスレッドで実現不能なことがほとんど。 637 名前：デフォルトの名無しさん mailto:sage [2011/06/29(水) 16:52:22.47 ] ある特徴が長所なのか短所なのかは目的次第（この話に限らない一般論） パフォーマンスいらないならマルチスレッドなんてしないだろ 638 名前：デフォルトの名無しさん mailto:sage [2011/07/23(土) 20:17:54.60 ] 処理中にUIが固まらないようにするためのマルチスレッドは よく使用されるが、それをパフォーマンス目的とは言わないだろう 639 名前：デフォルトの名無しさん mailto:sage [2011/08/02(火) 16:21:14.65 ] パフォーマンスだけがメリットだとしても、パフォーマンスのメリットは計り知れない からな クラしか見てない奴はパフォーマンス需要は頭打ちと思ってるかもしれんが、鯖は逆に クラウド化でクラの負担も全部引き受ける路線だから、パフォーマンスが非常に厳しく 求められるようになってる訳だし、鯖向けソフトウェアはパフォーマンス一つでシェア が取れる例も全く珍しくないしな 640 名前：デフォルトの名無しさん mailto:sage [2011/08/02(火) 16:23:33.58 ] ×クラウド化で ○クラウド化とか含めて 641 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 09:56:51.34 ] >>638 例が適切ではｱﾘﾏｾﾝﾈｰ UIを固めない = 操作者を待たせない = 操作者も含めたシステム全体のパフォーマンス向上、 という図式が成立するとも言う パフォーマンス向上以外のマルチスレッド利用としては、 非同期事象を取りこぼさずに受けるため、というのが挙げられると思うが、 それとて取りこぼさずに済むためのハードウェアの速度要件もしくはCPU時間消費の低減につながるため 結果的にパフォーマンス向上と言えなくもないという、 642 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 12:36:09.51 ] msdn.microsoft.com/library/cc464185.aspx これでおk 643 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 13:42:20.18 ] >>641 副次的な効果を目的に持ってこないほうがいい。 UIを固めないと中断が実現できたり、操作者のわかりやすさに繋がるんだよ。 それはパフォーマンス向上ではなく、別のことが目的だろう。 644 名前：デフォルトの名無しさん [2011/08/14(日) 13:58:19.75 ] >>643 例えばIDEがエディタを固まらせないでバックグラウンドでソースを解析するのは >操作者も含めたシステム全体のパフォーマンス向上、 になるんじゃないの? 645 名前：デフォルトの名無しさん mailto:sage [2011/08/15(月) 02:52:00.24 ] >>644 よく読めよ。 >>638が噛みついたのは「処理スレッドをUIと別にするのがパフォーマンス目的か？」 じゃなくて、 「マルチスレッドは必ずパフォーマンスが目的と言えるのか？」だろ。んなこたーない 646 名前：デフォルトの名無しさん mailto:sage [2011/08/17(水) 12:42:20.68 ] >UIを固めないと中断が実現できたり、操作者のわかりやすさに繋がるんだよ。 これをパフォーマンス向上と言ってもおかしくない dic.yahoo.co.jp/dsearch?p=performance&dtype=1 647 名前：デフォルトの名無しさん mailto:sage [2011/08/17(水) 18:54:09.83 ] >>646 どこを読めば良いのでしょうか 648 名前：デフォルトの名無しさん mailto:sage [2011/08/17(水) 19:21:06.24 ] うーん・・ ことプログラミングの文脈に関する限りはユーザーリスポンシビリティやユーザーエクスペリエンス はパフォーマンスの一部と解釈することはあまり無いんじゃないかな? 649 名前：デフォルトの名無しさん mailto:sage [2011/08/17(水) 20:51:02.93 ] >>646 おかしい 650 名前：デフォルトの名無しさん mailto:sage [2011/08/21(日) 09:04:32.75 ] 「パフォーマンスの向上」が何を意味するのか、が決まらないと無意味な議論だな その点に限れば、主観以外の論拠が出てこない（実際出てない）から、終着点なんか 無いぞ 元々MTのメリットという話題だったが、技術的に何の参考にもならん話だしどうでも いいんだが 651 名前： ◆0uxK91AxII mailto:sage [2011/08/21(日) 11:45:37.53 ] 意味を定義しても無駄な議論だけどね:b 652 名前：デフォルトの名無しさん [2011/09/09(金) 19:42:55.52 ] Ｃ＃のマルチスレッドのプログラミングです。 変数がいくつかある。例えばこんな感じ。 int A; int B; ・ ・ int Z; で、スレッド�@で定期的にA〜Zの変数の値を更新している。 スレッド�Aからこれら変数を読みたいのだが、必ずA〜Zまで全部更新された状態で読みたい。 （つまりスレ�@が更新処理中に読みに行くのはアウトってこと。） 優先度が高いのはスレ�@です。 どうやれば“スマート”なんでしょう？ 変数を更新している間スレ�@以外の実行を止めるような仕掛けがあるんじゃないかと思って探したんだけど無さそうだね。 653 名前：デフォルトの名無しさん mailto:sage [2011/09/09(金) 19:50:28.24 ] ttp://ufcpp.net/study/csharp/sp_thread.html 654 名前：デフォルトの名無しさん [2011/09/09(金) 20:10:35.64 ] >>653 それ、なんかちゃうで。 655 名前：デフォルトの名無しさん mailto:sage [2011/09/09(金) 21:29:06.03 ] >>652 途中で読まれてはいけない更新の開始から最後までロックする。 ロックが長時間にわたる可能性がある場合はSystem.Threading.Mutex.WaitOneで タイムアウトさせる。 656 名前：デフォルトの名無しさん mailto:sage [2011/09/09(金) 21:57:27.33 ] 1以外は読むだけなんだろ？ そりゃ System.Threading.ReaderWriterLock だろ 657 名前：デフォルトの名無しさん [2011/09/12(月) 00:26:16.03 ] 中途半端な状態で読むのがアウトってだけだったら、一つのクラスにA〜Zの変数をまとめておいて 更新時には丸ごと新しいインスタンスに差し替えてしまえばロックいらないよ 658 名前：デフォルトの名無しさん mailto:sage [2011/09/13(火) 18:08:55.63 ] RCUのめんどいところは古い情報をいつ削除するか 659 名前：デフォルトの名無しさん mailto:sage [2011/09/14(水) 18:37:15.35 ] C#での話だからGC任せでok あと、インスタンスへの参照を保持する変数にはvolatileを付けとけよ。 660 名前：デフォルトの名無しさん mailto:sage [2011/09/14(水) 21:28:32.04 ] この使い方だと実はつけなくても大丈夫だけどな。 つけとく方がいいけど。 661 名前：デフォルトの名無しさん mailto:sage [2011/09/14(水) 22:13:31.15 ] クライアントが古い方への参照を持ち続けていてはまると予想。 662 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 00:00:30.87 ] >661 の他にも、「新インスタンス上の変数A��Zへの書き込み」と 「共有変数を新インスタンスへの参照で更新」がリオーダーされないようにする必要がある。 663 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 00:24:43.65 ] .NET Framework 2.0以降（CLR2.0以降）のメモリモデルでは、 書き込み順をリオーダできないというルールがあるため、それは起こらない。 664 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 02:03:26.35 ] >>663 一般の変数に関しては、そんな規定は仕様書の何処にもない。 665 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 02:49:09.91 ] は？ 666 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 08:20:18.11 ] コンパイラが順序通りに書き込んでもCPUがそのように 振る舞うわけねーだろ 667 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 08:23:43.17 ] メモリモデルの意味も分かってない馬鹿ばかり。 668 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 08:45:27.59 ] >>666 お前はMSの文書ちゃんと読めよ 669 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 09:34:15.77 ] ちなみに読み込みは順序換えが許されている。 一般的には読み込み順序の問題でvolatileが必要になるんだが、 今回のような処理では、参照変数より先に参照先を読むことが不可能なため、 volatileがなくても実は問題が発生しない。 もちろん読み込みの挿入が許可されてないってのも重要なんだが。 まあ普通はvolatileつけるでOK。 670 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 10:44:40.93 ] >>669 いや、だから読み書きともに順序替えが許されてるんだってば 671 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 11:08:07.18 ] >>669 つけなくて大丈夫ってことは無いよ なにか別のパターンと勘違いしてないか？ 672 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 11:27:46.91 ] つけなきゃだめってのは、何を見て言ってるの？ CLR2.0のメモリモデルでは書き込み順序換えは許可されてない、 かつ読み込みを複数回に分ける事も許可されてない、 したがって今回のような処理では実質的にvolatileは不要。 このことはMSDNマガジンにも書かれてる内容。 673 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 11:28:52.30 ] >>670 書き込み順序換えは出来ないとはっきり書かれてる。 674 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 11:59:15.21 ] >>673 どこに？ CLIの仕様書にはどこにもそんなことは書かれてないが。 675 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:01:40.73 ] >>672 それはあんたがMSDNの記事を誤読してるだけだろ。 676 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:08:07.35 ] >>674 だから最初からCLR2のメモリモデルではと言っとろうに 677 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:13:29.95 ] >>675 どこを誤読してるのか明確に指摘してくれ。 ttp://msdn.microsoft.com/ja-jp/magazine/ee532386.aspx 正確には全く同じ話ではないが、結論は同じことになる話が出てる。 まあMSDNマガジンの例の方がより無茶な話も出てるけど。 678 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:18:55.76 ] C# よく分かんないけど、変数をまとめたクラス class Vars { 　　int a, b, c, ...; 　　static Vars instance; } があって、更新側 Vars v = new Vars(); v.a = aaa;　　// 1 v.b = bbb;　　// 2 v.c = ccc;　　// 3 ... Vars.instance = v;　　// 4 これで 1 〜 3 の順番が入れ替わるのは許せるけど、 1 〜 3 と 4 の順番が入れ替わるのってありなの？ まじ？？？ 679 名前：678 mailto:sage [2011/09/15(木) 12:21:02.84 ] 続き。volatile の必要性については、参照側 int prevA = 0; while (true) { 　　Vars v = Vars.instance; 　　if (v.a != prevA) { 　　　　doSomething(v); 　　　　prevA = v.a; 　　} } とすると、参照側の Vars.instance のアクセスがキャッシュされるから、 Vars.instance は volatile じゃないと駄目ってことでしょ。 Vars.instance を直接アクセスせずに getter を介してれば volatile は不要、かな？ 680 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:32:34.08 ] >>679 不要。 読み取りを削除出来るのは、同一ロケーションからの隣接した読み取りのみ。 よって読み取りが削除されることはない。 681 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:34:46.76 ] >>678 ECMAのメモリモデルではあり得るが、 CLR2のメモリモデルでは起こらない。 682 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 12:57:20.42 ] >>680 おっと、もう少し正確には、読み取りが丸ごと無くなってしまうような事はない。 683 名前：デフォルトの名無しさん mailto:sage [2011/09/15(木) 21:05:03.01 ] どうでもええけどえらそーに言ってたやつらが急に黙りこくってて笑えるぞ 684 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 02:54:28.89 ] >>677 それって、Xbox360のXNAとかWindowsPhoneとかでも同じなのかな。 IA-64版のメモリモデルをx86版とほぼ同じになるように修正したのは ビジネス的な判断としてはアリかもしれんが、 PowerPCやarmでも同じようにするのはオーバーヘッドが大きすぎると思うんだが。 685 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 10:38:04.13 ] 実行環境（.NET Framework）の話とC#などの言語の話がごっちゃになってる気がする。 .NET Frameworkのモデルでは書き込み順が入れ替わることはないが、 その前のコンパイラの段階で x = 1; y = 2;が逆転することはある。 686 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 11:50:25.42 ] ねーよ。 何のために変わるんだよ。 687 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 16:23:59.39 ] まあCLRのメモリモデルを頼りにしたければ、MSILで書けってこった。 688 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 17:16:22.88 ] メモリモデルに反するコンパイルを行うコンパイラがどこにあんだよ。 689 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 18:54:18.85 ] ＼ここにいるぞ！／ 690 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 19:10:50.21 ] ヒュー！ 691 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 19:37:52.18 ] ハンドコンパイラ､自由にコードを作成できる 692 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 20:11:33.77 ] 最近のコンパイラは最適化もしなくなったのか 693 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 21:18:28.10 ] 「最適化」を「何でもアリ」と勘違いしているヒトが居る模様 694 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 21:29:41.61 ] 実際問題、最近のマルチスレッドを前提とした中間言語処理系では、 昔みたいな静的コンパイル時の大胆な最適化は行わない。 というか、実行環境のCPUが想定できないので、あまり意味もない。 695 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 21:36:40.42 ] もっとも、可能性で言えばECMA仕様準拠のコンパイラならありえなくはない。 MSのコンパイラならあり得ない。 でも多分、ECMA仕様準拠のコンパイラでもそんなことはやらない気がする。 696 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 22:14:25.39 ] それこそ言語仕様次第でしょ。 たとえばCプログラムが、逐次一貫性メモリモデルに沿ったプロセッサで動く実行コードに コンパイルされるとして、じゃあ何が保証されるかというとCの言語仕様の範囲内でしかない。 書き込み順を入れ替えても、Cコンパイラとしては正しい。 697 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 23:26:17.69 ] だから最初から特定の処理系の話だよね。 698 名前：デフォルトの名無しさん mailto:sage [2011/09/19(月) 23:29:00.91 ] そして言語仕様だけでは定義されてない範囲ってものがある。 C言語仕様だけじゃマルチスレッドにおいて何もできない。 699 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 00:11:35.17 ] 結局、>678の質問の答えはどうなん？ CLRの仕様から答えは決まるのか、 それともC#も仕様で決まるのか？ 700 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 00:14:14.83 ] >699 >698が言ってる通り、C#の仕様では1-4の実行順序は規定されていない。 よって、リオーダーは起こりうる。 701 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 00:41:04.58 ] C/C++の仕様だと、;等のシーケンスポイントの前後での入れ替えは 起こらないことが規定されてるけどな。 機械語の書き込み順が、現れた順番で行われるかどうか、という点には 何も規定されていない。JVMやCLR等はそういう点にも言及されていると。 702 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 00:55:54.52 ] それはCプログラムの意味（抽象機械上での振る舞い）定義でしかないよ。 意味が変わらなければ入れ替えは許される。 （そうでないと、ループ不変式移動すらできない） 問題は、Cプログラムの意味定義は実行の流れがひとつという前提でなされていること。 703 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 00:58:37.26 ] ついでに機械語命令の実行順は、プロセッサの仕様で規定されている。 もちろん未規定な部分もあるけどね。 704 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 01:14:32.80 ] ？？？ 705 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 01:18:24.02 ] >問題は、Cプログラムの意味定義は実行の流れがひとつという前提でなされていること。 C#の言語仕様では、別スレッド等ではなく突然実行が複数になったり入れ替わったりすることを許しているわけ？ >ついでに機械語命令の実行順は、プロセッサの仕様で規定されている。 CLRでは規定されてないとでも？ 706 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 01:26:01.83 ] さっきから暴れてる方、 ＞>698が言ってる通り、C#の仕様では1-4の実行順序は規定されていない。 や ＞意味が変わらなければ入れ替えは許される。 の出展を示してくれませんかね。 それぞれ、C#の言語仕様とCの言語仕様の、どの部分で言及されているのか。 でなければ、ただの脳内妄想と区別がつきませんので。 707 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 01:48:51.52 ] その通りだと思うが出典だぞ 708 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 02:28:18.91 ] C#言語仕様の範囲では、 C#言語仕様の 3.10 実行順序 および 10.5.3 Volatile フィールド で規定されてる。 でMSの.NET Frameworkの実装としては、何度か出てるCLRの仕様に則っている。 709 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 08:38:12.37 ] コンパイラが実行順序かえたら駄目だろ 710 名前：708 mailto:sage [2011/09/20(火) 09:28:06.57 ] 念のため、俺は>>700ではない。 711 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 09:28:42.41 ] レベルひくっ 712 名前：デフォルトの名無しさん mailto:sage [2011/09/20(火) 10:22:38.97 ] 　　　　　　　　　　　　　 ○＿＿＿＿ 　　　　　　　　　　　　　 .||　　　　　　| 　　　　　　　　　　　　　 .||　　●　　 | 　　　　　　　　　　　　　 .||　　　　　　| 　　　　　　　　　　　　　 .||￣￣￣￣ 　　　　　　　　　　　　　 .|| 君が代は 　　　　　　　　　 ∧__,,∧|| 千代に八千代に 　　 　　　　　　　( ｀･ω･||　さざれ石の巌となりて 　　　　　　　　　　ヽ　 つ０ 　こけのむすまで 　　　　　　　　　　 し―-J 713 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 11:34:40.79 ] >>708 C#言語仕様もCLRの仕様も、またECMAのCLI仕様においても、 全部「命令のリオーダーが許されるか否か」の視点でしか 記述されてないんだよね。 例えばCLR2.0においては、同一スレッド内の書き込みの順序は 入れ替えられないとされてるようだけど、実行環境がx86であれば それは単に「コンパイラがプログラムを機械語に落としこむときに 書き込み命令の発行順を入れ替えない」とするだけで実現可能。 x86 CPUのメモリモデルは非常に強いので、アウトオブオーダー実行などによって、 ある書き込みが先行する書き込みより先にglobally visibleになることは認められていない。 714 名前：713 mailto:sage [2011/09/23(金) 11:35:46.25 ] でも、PowerPCやarmでは事情が違ってくる。 これらのCPUのメモリモデルはx86よりもずっと緩いので、 単に「コンパイラが書き込みの順序を入れ替えない」とするだけだと、 CPUによるリオーダーによって「他スレッドからは書き込み順が 入れ替わったように見える」ことが起こりうる。 一方で、このようなCPUによるリオーダーまでも防ごうとすると、 ほとんどの書き込み命令の間にメモリバリア命令を挟まなきゃ ならなくなる。当然、パフォーマンスの低下はとてつもない。 .NETのメモリモデルって、x86のことしか考えてないように見えるんだよね。 JavaやC++11のメモリモデルは、そういう「リオーダー禁止」とかの 直接的視点ではなく、もっとメタなレベルで「ある書き込みが ある読み込みからはvisibleか否か」を定義してるので、 x86以外のアーキテクチャでも実装しやすくなっている。 今後、マルチコアなWindowsPhoneが出てきたときに いろいろ酷いことになったりしなきゃいいが。 715 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 18:44:38.36 ] 実際にitanium版とかあるわけで、実用上なんとかなるレベルだったんじゃないの？ 716 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 18:48:00.72 ] あとCLIとかのメモリモデルもリオーダはメモリの可視性を含めた話だよ。 キャッシュの影響で、実質的に順序が変わったように見える話とかも出てきてるんだから。 特にECMAの仕様はかなりjavaに近いと思うが。 ていうかほとんどjavaと変わらんような。 717 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 18:52:07.56 ] 書き込み毎にメモリバリアいるんじゃないかってのは俺も疑問無くはないんだけど、 多くのCPUではこのルールを守るのは大してペナルティはないというのも読んだことがあって、 実際のとこはよく分からない。 718 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 18:54:03.30 ] 何が言いたいのかわからんなあ 719 名前：! 【14m】 【東電 66.0 %】 mailto:sage [2011/09/23(金) 18:58:34.31 ] ペリフェラルいじるときは エイエイオー しまくりだ 720 名前： ◆0uxK91AxII mailto:sage [2011/09/23(金) 20:02:20.23 ] CLRなんて作らないから、どうでも良い。 721 名前：デフォルトの名無しさん mailto:sage [2011/09/23(金) 22:55:12.81 ] >>715 Itaniumで.NETアプリを動かすのって、基本的には x86のWindowsサーバー上のアプリをそのまま持っていきたい ってニーズがほとんどだろうから、その場合はパフォーマンスより先に 互換性確保のほうが最大限に重視されるだろうね。 722 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 03:15:05.37 ] C++0xとCLRとJavaのメモリモデルの違いとか考えたこともない話だわ マルチスレッドに詳しいひとは普段どんな仕事してるんだろ 723 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 10:21:23.71 ] 排他に必要なメモリバリア類をライブラリだかCLRだかVMだかがやるんじゃないの。 そこを超えて踏み込む（＝排他をケチる）とメモリモデルの違いが表面化するとか？ 俺の持論：volatileで十分ｗ 724 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 11:58:45.66 ] volatileの言語仕様知らないだろｗ 725 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 15:39:38.60 ] volatileを信用してると痛い目合うコンパイラもあるぞ 726 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 15:56:04.66 ] 会う 727 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 17:11:35.69 ] コンパイラからバールのような物が飛んでくるのですね 728 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 17:55:34.09 ] perlのようなものか 729 名前：デフォルトの名無しさん mailto:sage [2011/09/24(土) 18:18:48.58 ] >>716 ECMA-335はvolatile変数についてrelease-acquireバリアは要求してるけど、 sequential consistencyは要求してないように見える。12.6.7には > a conforming implementation is not required to provide a single total ordering > of volatile writes as seen from all threads of execution. とも書いてるし。 730 名前：729 mailto:sage [2011/09/24(土) 18:20:59.69 ] >>716 だから、ECMA-335において、たとえば以下のようなコードでは volatile int a = 0; volatile int b = 0; Thread1: { a = 1; int r1 = b; } Thread2: { b = 1; int r2 = a; } r1 == 0 && r2 == 0 という結果も許されるんじゃないかな。 一方で、JavaのvolatileやC++11のstd::atomicはこういう結果を許さない。 731 名前：デフォルトの名無しさん [2011/09/24(土) 19:22:11.48 ] .NETではInterlocked使うんだよ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef