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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 17:44 / Filesize : 232 KB / Number-of Response : 919
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]: マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室その６
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/

■過去スレ
その１ 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/

OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ

【ＯＳ】

【言語】

【実行環境】

【その他突起する事項】
697 名前：デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:12:44 ]: シングルはあるよな
698 名前：デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:14:07 ]: まぁ「プログラムなんてとりあえず動けばいいや」と考えている奴は大抵マルチスレッド関連でバグ出してハマるしな。
699 名前：デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:19:51 ]: >>698
そういうのは未だ救いようがあるが自分の痛さに気づいていない
プログラマーは救いようが無い。
700 名前：696 mailto:sage [2009/08/29(土) 11:39:02 ]: よく見たらゴミ記事であるな。
参考にしないほうが良い。ｽﾏﾇ Orz
701 名前：696 mailto:sage [2009/08/29(土) 11:47:41 ]: ゴミ記事って言うのは酷すぎた。。
前提知識のない初心者が見ると混乱すると言うのが正しい。
702 名前：デフォルトの名無しさん mailto:sage [2009/08/29(土) 18:11:28 ]: 冒頭の四行くらいで日本語も問題切り分けも怪しく感じたから流し読みしたけど
どうでもよさそうな記事だった
703 名前：デフォルトの名無しさん mailto:sage [2009/08/29(土) 21:52:57 ]: シングルトン実装から始まって愚駄ぐだになって終わってると。
704 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2009/08/30(日) 10:25:00 ]: >>696の記事の二重チェックロックなんだけど

if (_Value == null) {
　lock (ValueLock) {
　　if (_Value == null) {
　　　A temp = new A();
　　　Thread.MemoryBarrier();
　　　_Value = temp;
　　}
　}
}
Return _Value;

これだと_Valueが更新される前にlockから抜ける可能性ない?
Thread.MemoryBarrier()するのは_Value = temp;の後じゃないの?
705 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:05:55 ]: _Valueの代入はlockの中にあるから、_Valueが更新される前にlockを抜けるわけはない
第2のスレッドがやってきて外側のif(_Value==null)を見たときに、
もし_Valueがまだnullならlockに引っかかるから最初のスレッドが更新を完全に終えるまで待たされるので問題ない (lock/unlock自体がメモリバリアになる)
問題は_Valueがすでにnullでなかった場合、_
Valueは新しいオブジェクトを指しているけれども_Valueの中のフィールドはまだ更新されてない、という事態が起きうる (メモリの書き込み順序は勝手に並び替えられるので)
それを防ぐためにメモリバリアを挟んで、_Valueが更新されるよりも前に_Valueの中身が更新されることを保証している
706 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:28:19 ]: _Valueが更新されるよりも前に_Valueが参照されないことを保証している
707 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:35:51 ]: _Valueへのアクセスは同期されてないから、lock中で_Valueが更新された直後から
他スレッドからAが使えるようになる。
でも

Aの構築
_Valueの更新
Aの構築の結果がAのフィールドに反映される

となる可能性があり、不完全な状態のAが使われる可能性がある。
だからAをnewした後にThread.MemoryBarrier()してから_Valueに代入する。
_Valueへの代入はlockを抜ける段階で保証される。

ということか。
勉強になった、ありがとう。
708 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:39:37 ]: 一応はっておく
www.ibm.com/developerworks/jp/java/library/j-dcl/
709 名前：デフォルトの名無しさん [2009/09/01(火) 20:32:30 ]: クアッドコアを使った並列処理を
MFCでのマルチスレッドでやろうとしておりますが、
シングルコアのときと同じマルチスレッドのプログラムでも
4つのコアを利用した並列処理になるんでしょうか？
710 名前：デフォルトの名無しさん mailto:sage [2009/09/01(火) 20:34:22 ]: なるよ
711 名前：デフォルトの名無しさん [2009/09/01(火) 20:38:55 ]: >>710
そうっすか！ならよかったです。
712 名前：デフォルトの名無しさん mailto:sage [2009/09/01(火) 21:08:29 ]: erlang
713 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 00:40:31 ]: >>709
MFCには詳しくないけどシングルコアで問題なく動いてたMTセーフのつもりの
プログラムがマルチコアにもってくと異常動作することはそれなりにあるん
じゃないの？int型への代入・参照を非同期でやってたりするプログラムだと。
714 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:07:14 ]: >>713
何故int? 64bit整数ならわからんでもないけど。
715 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:11:11 ]: つーかそんなことを質問してるわけじゃねーし。
言ってみたかっただけだろ。
716 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:05 ]: intでもread-modify-writeはatomicじゃないぞx86は（も）
717 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:42 ]: >>709
なる。OSネイティブのスレッドは、明示的に指定しない限り、複数のコアに分散される。
とは言え、排他制御が適切でないと、各コアを有効に利用できないけど。
718 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:27:46 ]: >>716
いや、それだったらそもそもデータ型問わんのでは。
719 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:33:30 ]: いやいや、おまいら、それ以前にそれはスレッドセーフと呼ばないのでは。
720 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 02:19:59 ]: >>718
64bitなら、と言ってるから、マシンワードならアトミックと思ってるのかなと思った
721 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 03:38:51 ]: volatile
722 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 06:06:12 ]: volatileがどうかしたか？
723 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 09:42:27 ]: vottakle
724 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:14:01 ]: 明白な答えが、ここで出せるわけ無いんだから。
あなたが欲しいのは同意なんじゃないの？だから荒れる。
725 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:37:33 ]: >>724
独り言が言いたいだけだ、とかでないなら
最低限アンカーくらい書いたら？
726 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:55:09 ]: >>725
ごめんめっちゃ誤爆
727 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:57:38 ]: 　　　　　　　　∧∧
　　　　　　ヽ(･ω･)/　　ｽﾞｺｰ
　　　　　＼(.＼ノ
　　　　､ﾊ,,､　￣
　　　　￣
728 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 14:27:31 ]: >>696
いまひとつ怪しい記事だな。
だいたい今の.NETじゃ前提が変わりすぎてて、役にたたないどころか害のが多い気がするし。
729 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:22:08 ]: >>720
64bitを持ち出したのは、32bitマシン(あるいは32bitモード)だと、単一の書き込み/読み出しでも競合すると値が壊れる可能性があるから。
(最初の32bitが書き込み前の、次の32bitが書き込み後の値を読み出す可能性がある)
マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?
あと、x86系だと、ワード境界をまたぐ読み書きがどうなるかがよくわからない。
730 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:40:02 ]: P6以降はキャッシュアラインドなマシンワードのreadやwriteはアトミックだよ
read-modify-writeはLOCK#がassertされないとアトミックじゃないよ
xchg命令は昔からLOCK#がassertされる仕様だからアトミックだよ

コンパイラも含めた挙動はこの辺も参考にするといいよ
msdn.microsoft.com/ja-jp/library/bb310595(VS.85).aspx
731 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:48:23 ]: ttp://www.intel.com/Assets/PDF/manual/253668.pdf
ここの 8.1 LOCKED ATOMIC OPERATIONS を嫁
732 名前：デフォルトの名無しさん mailto:sage [2009/09/02(水) 22:01:55 ]: >>729

>マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?

w
733 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 00:09:10 ]: The Art of Multiprocessor Programming
糞本だなぁ
734 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 03:59:45 ]: volatile
735 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 05:34:09 ]: volatile変数へのアクセスのアトミック性は、non-volatileな変数へのアクセスと同じ
だから、この流れにvolatileは何の関係も無いよ
736 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 09:27:34 ]: >>706
読み取り側ではメモリバリアはいらないの？
737 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 10:14:24 ]: _Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない・・・んじゃないかなたぶん
738 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:09:34 ]: >>737
＞_Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
＞メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない
それが成り立たないアーキテクチャもあるんだな。
www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html
739 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:31:35 ]: volatileの話をするときは、C/C++なのかJava/C#(CLI)なのかをはっきりさせろ。
それぞれのvolatileの意味はまるっきり別なんだからな。
740 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:59:30 ]: そうか、やっぱりだめか
例の記事は今見直したらvolatileが付いてるな
なるほど
741 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:18:16 ]: それはメモりバリアかvolatileどっちかって話だから意味ないよ
742 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:36:48 ]: そろそろvolatileについて一言いっておくか
ttp://d.hatena.ne.jp/bsdhouse/20090720/1248085754
743 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:04:04 ]: C++っていつまでAtomicIntegerとかないわけ？
ふざけてないか？いい加減にしろ
744 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:06:40 ]: と言われても今年決まる新標準には採用されてるし
一企業や一個人に独占されてる言語と比べるなよ
745 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:10:45 ]: >>744
C++0xは2012年まで延期でしょ
今すごい揉めてるでしょ
746 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:13:31 ]: つーかC++使うならそのくらいはライブラリかAPIか自力で何とかできないと
結局他でつまづく
747 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:23:59 ]: ちょっと来週あたり
C++のatomic実装投下するから誰か100%
厳密に正しいか判断できる人いますか？
748 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 23:38:00 ]: 投下してから聞け。
749 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 00:20:53 ]: 現行C++ + Boost + TBBで組んでおけば、C++0xの時代になっても
スムーズに移行できるんじゃないかな
750 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 22:04:46 ]: 最近はC++の仕事が減ってC#とCばっかりになったお
751 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 23:55:21 ]: blueroad.sakura.ne.jp/entry/20070815.php
752 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 00:54:22 ]: gccだとvolatileは付けても付けなくても
効果ないんだね
753 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:06:06 ]: SomeType() = default;

って奴を普通のC++に直すと
どうやってかけばいいの？
754 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:11:29 ]: >>753
// SomeType() = default;
755 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 04:53:21 ]: gccでもvolatile付けたら本来のvolatileの効果はあるだろ
756 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:45:20 ]: ちゃんと実装されているマルチスレッドアプリってあるのだろうか。
このスレ見てるとある特定の条件下でたまたま運良く動いているアプリばかりじゃないかと思ってしまう
757 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:50:07 ]: たまたまでもバグが入り込まなかったのならすばらしいことです
758 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:17:49 ]: このスレだけが世界のすべてだと想うなかれ
759 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:20:06 ]: 引っ掛かりやすい問題点は多々あるが、ちゃんと分かってくれば安全に書ける
ただ、その「分かってくる」までのハードルがそれなりに高いから、手を出せる開発者
もなかなか増えないし、MTに対応することで恩恵の得られるアプリも少ないから、
MT対応アプリそのものがなかなか増えない訳だが
IntelもMTのフレームワークで金取ってる余裕ねーだろうにと思う（MSあたりは別に
どっちでもいいんだろうが）
760 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:09:19 ]: >>752 は

const volatile int x;

の説明も出来無さそうだな。
761 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:11:26 ]: ああ、const volatileの意味がすんなり理解できるかどうかはいいテストかもなｗ
762 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:50:26 ]: それがconst volatile autoな変数なら私には理解できません。
763 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:13:34 ]: C++0xのautoってcvとか*とか&とか付けられるんだろうか
764 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:27:55 ]: >>760
最適化されないRead Onlyな変数以外に何かの意味があるのか？
765 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:06 ]: 別に最適化されない訳でもないが
766 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:18 ]: >>758
日本のマルチスレッドプログラム界の縮図がこのスレだと思っておりますが。
767 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:33:20 ]: ここには「実戦ではまだまだ書けませんが」って人もかなりいると思われ
768 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:39:42 ]: >>767
そういうヤツは時間の問題でちゃんと書けるようになる。
そんな自覚のないヤツほどマルチスレッドを使いたがる。
769 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:40:11 ]: 「C/C++の」volatileを誤解してる奴はこれ↓読んどくといいぜ
ttp://mkosaki.blog46.fc2.com/blog-entry-91.html
770 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 13:58:48 ]: マルチスレッドってコンパイラの最適化やCPUの命令の実行順序まで
いちいち気にしていないとまともなプログラムは作れないって事ですか？
771 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:23:36 ]: いいえ
mutexやcondvarの使い方を知っていれば問題ありません
772 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:28:32 ]: mutexは遅いからイヤだ、などと言い出すから話がややこしくなるだけです
773 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:30:03 ]: condvar?
774 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:35:10 ]: 条件変数
win32ならイベントオブジェクトか何か･･････特定の出来事を待って寝ているスレッドを起こすメカニズム
775 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:17 ]: スレッド間通信そのものがボトルネックになるような場合は、mutexなんか使って
られないから>>770は真に近い
スレッド間通信のコストが無視できる場合は、>>770は偽に近い
776 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:37 ]: >>769
そのブログのおっさんって何者なんですか？
777 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:45:40 ]: スレッド管理APIを作る側なら>>770は真
778 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:07:19 ]: >>770
単純に動くものを作りたいなら、そこまでローレイヤーのことを考える必要はない。
が、
プログラムのパフォーマンスを上げたかったりするんだったら、
考える必要が絶対に出てくる。
「まともなプログラム」==「メジャーなソフトウェア」って認識なら、
言う通り、そこまで考えないとまともなプログラムは作れない
779 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:08:26 ]: >>770
適当に作ってはったりかます方が金になるから
きちんとモノ作りする奴は馬鹿を見ると思った方がいいぞ
780 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 10:56:31 ]: mutexの速度が気になるようなプログラムなんて組んだことないぜ
速度より安定性重視な俺はプロだって周りかよく言われます
781 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 12:28:25 ]: 必要無いならそれでいい
カーネルやドライバを書いてるような連中はそういう訳にはいかない
科学技術計算やゲームエンジンを書いてるような連中もな
782 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:20:16 ]: 正しく動くものできっちり金を取った後、
また高速化するたびにきっちり金を取るのはプロだと思う。
783 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:31:25 ]: 最初からある程度高速じゃないと金の取れない業種もあるけどな
784 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:14:35 ]: そういうプロが幅を利かせるから日本のIT業界はいつまでたっても土方っていわれるんだろな
785 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:18:37 ]: よく知らんけど海外でもそういう手合いはいるんじゃね？
変に胸張って「俺らこそがプロ」みたいな顔をしてるかは別として
Googleみたいなとこのプロはそういう手合いとは思えないしな
786 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 16:34:28 ]: >>780に同意する。

いかにmutexの回数やクリティカルセクションの範囲を減らすかに設計能力を注ぐ。
要は、スレッド間の同期を減らし、スレッドの並列度を上げることが目的。
ただし、(>>770の言う)コンパイラの最適化やCPUの実行順序までは考えない。
(>>782の言う)正しく動くものを作ることを最優先する。

マルチスレッディングと、その最適化には、高度に抽象化された思考能力と設計技術が要求される。
(>>778の言う)ローレイヤのことを気にした(言い換えると、ローレイヤの振舞いを前提にした)
スレッディングのロジックを組むということは、プラットフォーム依存な設計であるということ。
(>>781の例であれば)科学技術計算ならUNIXからWindowsへ、ゲームエンジンならPS3からXBoxへ
移植するたびにロジックの再設計が必要になる。

もしかすると自分が知らないだけで、(意図的に？)そういうローレイヤ前提な設計をして、
移植の度に利益を得るという(>>778,779,781のような)世界があるのかもしれない。
ただ、それは(>>784の言う)土方仕事と呼ばれる日本のIT業界の縮図そのものであると思う。

例外があるとすれば、カーネルの、しかもスレッドスケジューラやmutexそのものを実装する
コアなデベロッパに限る。彼らはハード(CPU)の能力を最大限に生かす基盤を作る人達だから。
787 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:00:35 ]: いや、普通に移植性の高いlock-free queueとか書けるから。
788 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:04:16 ]: ハードリアルタイムやったことないやつって性能無視の安定指向が強いよな
789 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:07:38 ]: マシンパワーの需要と供給の比がカツカツかトントンか余りまくりかで全然違うからな
それを無視して、どれか一つのパラダイムだけで語る奴は問題がある
790 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:08:37 ]: CompareAndSetとか、既に
どの開発環境でもインラインアセンブラ関数
用意されてるから、CPU変わっても大した話
じゃないよ
791 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:24:48 ]: ところでお前らlock-free queue
とか朝飯前なんだよな？

なぁどうなんだ？
792 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:28:54 ]: >>789
ですよねー周りの見えない技術者ほど使えない物はないです
793 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 19:15:48 ]: 物理シミュだと、精度が要るところは安定性重視でそうでないところはピーク性能重視。
マシンパワーの配分はジョブによって違うから動的に。
794 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:30:11 ]: >>791
Javaのマルチスレッド本にlock-free queueの実装が載ってたんだが。
「どうやってlock-freeを実現しているのか」は何とか理解できたが、
自分で一から書けるか、と聞かれると胸を張って「No!」と答えるしかない。
795 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:32:03 ]: >>791
俺は今書いてる
書いたらここにうｐして

虐めて貰おう
796 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:00:21 ]: 要求条件によって実装も細かく変わるからなぁ、lock-freeは
797 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:08:59 ]: IntelのMathKernelLibraryはやばい
あれこそプロの仕業だ

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

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