10/07/07 22:49:02
＞まともに組んだことがない人の記事だな
URLﾘﾝｸ(blogs.wankuma.com)
まともに組んだことはあまりないようだなｗ
428:デフォルトの名無しさん
10/07/07 23:20:11
なぜ？
Posted @ 2010/07/07 22:46
＞スレッドの終了を、もうちょっとスマートに待てないのかなぁ？まぁ、動いてるからいいや。
全然よくありません。
Sleep(0)を入れているとはいえ、無駄なループでCPUを使用していては、まともな計測はできません。
コア数以上にスレッド数を増やしても改善していってしまうのは、これも原因なのではないですか？
＞おかしいと思ったらできるところまで追求する。それが職人ってもんじゃないですかねー。似非職人はヤーネー。
いくらなんでもこんなこと言いながらこれではダメでしょう。
429:デフォルトの名無しさん
10/07/07 23:44:31
本人に言えよ
430:デフォルトの名無しさん
10/07/07 23:57:00
おまえならできる
431:デフォルトの名無しさん
10/07/08 00:19:44
？
432:デフォルトの名無しさん
10/07/08 00:24:16
本人？
433:デフォルトの名無しさん
10/07/08 01:19:38
馬鹿が呟いているだけだから無視でいいだろ。話題にすらならん。
434:デフォルトの名無しさん
10/07/08 01:42:21
ヲチスレじゃないしな
もう少しマシな話題ならともかく、内容がどうでもよさすぎる
435:デフォルトの名無しさん
10/07/08 01:58:28
最近話題がない
436:デフォルトの名無しさん
10/07/08 02:29:13
くだらないネタで流れるなら止まってた方がずっといい
437:デフォルトの名無しさん
10/07/09 11:00:47
マルチスレッドと関係ないかもしれないけど、
CPUって忙しくないときどんな状態になってるんですか？
割り込み待ち状態なんですか？
それともなんらかの無限ループ状態なんですか？
438:デフォルトの名無しさん
10/07/09 12:15:51
忙しくなさ次第でいろいろ
439:デフォルトの名無しさん
10/07/09 21:49:46
>>437
ちょっと暇なときは、いっしょうけんめいだらだらしてる。
だいぶ暇なときは、夢の国へいく。
440:デフォルトの名無しさん
10/07/09 21:49:51
>>438
アイドリング状態
441:デフォルトの名無しさん
10/07/09 22:03:35
URLﾘﾝｸ(img.20ch.net)
442:デフォルトの名無しさん
10/07/09 23:35:26
SUZUKAサーキット
URLﾘﾝｸ(www.youtube.com)
443:名無しさん＠そうだ選挙に行こう
10/07/10 06:31:23
>>440
それじゃ何の説明にもなってない
つーか環境次第で千差万別だから、本気でそういう情報が必要なら仕様書を当たるといい
単に何となく興味があって聞いてみた程度なら、めんどくさいから知らなくていい
仮にx86なら、暇になったらHLTかPAUSEを仕込んでおくことが多いだろうけど、そうで
ないのもあるし、単純にHLT発行すればいいって話でもないし、そもそもぶっちゃけた話、
全く知らない奴に頭っから全部説明してらんね
halt状態の休み方も何段階もある訳だし
444:デフォルトの名無しさん
10/08/12 12:18:23
>ちょっと暇なときは、いっしょうけんめいだらだらしてる。
スピンロックか
445:350
10/08/17 20:53:09
「マルチスレッド」の説明する時に「マルチタスク」の状態遷移持ち出す奴がいて、俺的には「？」なんですが、そういうのありなんですか？
446:デフォルトの名無しさん
10/08/17 21:25:38
プロセス空間が分かれていない頃の書籍でマルチタスク学んだ人なら普通じゃね？
447:デフォルトの名無しさん
10/08/17 21:34:57
>>445
大して難しい話じゃ無いし、基本だから知っておくべきだろう。
448:デフォルトの名無しさん
10/08/17 22:30:37
リアルタイムOSの「タスク」は、Unixのスレッドのようなものだったりするぞ。
449:デフォルトの名無しさん
10/08/21 13:56:10
>「マルチタスク」の状態遷移
て何ぞね
DORMANT/WAITING/RUNNINGとか言った類類の話ならタスク単体の状態だし
タスク同士の関係は非同期というのがマルチタスクの本性であるからして、
複数タスクに渡る状態など一般には規定しようがない
設計者がタスクそれぞれに明示的に同期ロジックをプログラムしたという想定で、
その詳細が明かにされた上でなら話は別だが
450:デフォルトの名無しさん
10/08/29 12:59:13
まあ、>>445は理解できなかったって言ってるんだから説明も出来ないだろう
451:デフォルトの名無しさん
10/10/01 17:29:29
あんまり理解できてないのでうんこみたいな質問申し訳ないんだけど、
スレッドが二つ(A,B)あって、
変数 int a にスレッドAがひたすら数字を入れて、スレッドBはひたすらその数字を読むだけの場合、
int aの書き込み・読み込み時にクリティカルセクション使う必要はある？
手元で試してみたら片方が読み込みオンリーの場合正常に動いたんよね
452:デフォルトの名無しさん
10/10/01 18:10:07
移植性のあるコードを書こうと思ったら必要なる。
ただハードやOS・言語・コンパイラ・ライブラリなどが想定するメモリモデル
（平たく言えばマルチスレッドでメモリがどう見えるかのルール）によっては
それで正しいケースもある。
具体的な回答が欲しいならpthread、Win32のスレッド、Javaや.NETくらいの
くくりで質問するといいよ。
453:デフォルトの名無しさん
10/10/01 18:34:06
>>451
まず、書き込まれた値が化けたりせず正常に読めるか、という点については
適切にアラインされている、CPUのワードサイズ以下の値なら、まず問題ない。
Cコンパイラにおいて、「int」として扱われる値を
Cコンパイラに配置させる場合は、まず大丈夫。
ただし、スレッドAが書き換えた後にスレッドBが読み出したとき
直前の変更が適切に反映されているかどうか、については
環境依存、というか普通は保証されない。
454:デフォルトの名無しさん
10/10/01 18:41:34
一方通行なら問題ないでしょ
455:デフォルトの名無しさん
10/10/01 18:44:58
他に受け渡すデータが一切どこにも何もなくて、ただその数字1個を渡せばいいだけなら
456:デフォルトの名無しさん
10/10/01 18:49:48
ハード依存ＯＫということならシングルＣＰＵのＰＣは
スレッドに関するほとんどの問題発生しないし正常に動くね。
457:デフォルトの名無しさん
10/10/01 18:55:25
読み出しで値を比較するときはちょっと考えないといけないかも
458:デフォルトの名無しさん
10/10/01 18:57:15
>>456
いくらなんでも、理解して無さすぎ
459:デフォルトの名無しさん
10/10/01 18:57:30
>>452
すまん、VC++で、Win32APIのCreateThread使った話だった
>>453
ｔｈｘ 直前の変更は特に気にしなくてもよさそう
取り扱う変数がvectorとかlistになってくるとまた違うんかな……
460:デフォルトの名無しさん
10/10/01 22:14:34
ひたすらスレッドＡが書き込んでスレッドＢが読み出してprintfするだけなら正しく見えるが、
例えば、イベントを受け取ってスレッドＡが書き込もうとして、スレッドＢは読み出すとき、
読み出された値はスレッドＡが書き込こむ前か後かはＣＰＵの気まぐれになりそうな気がする。
まぁそんな時はロックしなくてもスレッドＡが書き込み終わったらスレッドＢに読み込むように言えばいいけど
461:デフォルトの名無しさん
10/10/01 22:32:14
Win32での32bit読み書きはアトミックな操作だっけ?
462:デフォルトの名無しさん
10/10/01 22:38:21
Windowsならここ読んどきゃいいよ
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
463:デフォルトの名無しさん
10/10/02 04:07:15
>>461
Win32の環境じゃなくIA32とかx64の意味でじゃないの？
464:デフォルトの名無しさん
10/10/02 10:36:20
i386SXのように外部データバスが16bitのものはどうなるんだろ。
i386SXでマルチプロセッサ構成は見たことがないけどね。
465:デフォルトの名無しさん
10/10/02 10:56:16
たぶん、データが化ける可能性があると思う。
386SX以外にも、68000とか8088とかがその系統だったと思うし
今後も組み込み向けとかにそういうのが出てこないとは言い切れない。
だから、「intなら大丈夫」じゃなくて「intなら普通は大丈夫」程度。
とはいえ、組み込み向けのバス幅制限があるような環境では
マルチスレッドはともかく、
マルチプロセッサ/マルチコアはまずありえないと考えて良いんじゃないかな。
466:デフォルトの名無しさん
10/10/02 11:02:40
そもそも、lock prefix使えないはずなので、マルチプロセッサが構成出来ない。
467:デフォルトの名無しさん
10/10/02 11:03:07
386SXの32ビットR/Wや8088の16ビットR/Wは、読み書きは複数サイクルかもしれないけど、
完了するまで割込まれないんじゃなかった？ 仕様書見て言ってるわけじゃないけど。
同じような構成で割込まれるプロセッサもあるかもしれないけど。
468:デフォルトの名無しさん
10/10/02 11:50:37
32bitのアクセスがアトミックであると保証されてるのはi486以降とIntelの資料に書いてある
469:デフォルトの名無しさん
10/10/02 12:09:53
>>467
割り込みは確かに発生しないから単一コアのスレッドなら問題はないが、
マルチコア・CPUの場合は問題が発生する。
470:デフォルトの名無しさん
10/10/02 12:18:00
んでi386SXのマルチプロセッサやマルチコアは実在するの？
471:デフォルトの名無しさん
10/10/02 12:46:22
SXかどうかはわからないが386のマルチプロセッサはあったらしい。
URLﾘﾝｸ(ja.wikipedia.org)
プロセッサレベルの割込みじゃなくて、バスの読み書きがどうかということだと思うんだけど。
472:デフォルトの名無しさん
10/10/02 12:55:16
>>471
それはi386DXだな
473:デフォルトの名無しさん
10/10/02 14:15:52
ハードのことわからんのに憶測で書くなよ
474:デフォルトの名無しさん
10/10/02 15:18:15
>>468
i386まではDMA操作なら割り込めた、CPU単体でならアトミックだったがSXでマルチプロセッサ組んだらダメだろうと思う
475:デフォルトの名無しさん
10/10/02 15:22:14
小数点付きのプログラムカウンタのあるCPUでも使ってるんかね
476:デフォルトの名無しさん
10/10/02 22:16:44
>>475
パイプラインの途中を指し示したいみたいな？
477:デフォルトの名無しさん
10/10/02 23:05:16
たぶん475は、全ての命令が1クロックで実行できると思ってる。
478:デフォルトの名無しさん
10/10/02 23:52:07
intelのは１クロックで動くんじゃないの
479:デフォルトの名無しさん
10/10/02 23:58:09
ワイヤードロジックをほぼ全体に使うようになったのは486から
480:デフォルトの名無しさん
10/10/03 00:08:11
>>467
割り込みと、トランザクションをごっちゃにしてる？
CPUの割り込みはR/Wの間に中断しないだけ。
マルチプロセッサについてはRとWが別のトランザクションなんでR/Wの間に別のプロセッサのRやWが割り込める。
この割り込みを防ぐ信号を駆動するのがインターロック命令
481:デフォルトの名無しさん
10/10/03 01:17:48
URLﾘﾝｸ(gcc.gnu.org)
482:デフォルトの名無しさん
10/10/03 11:49:42
読む側が、変更されない変数読んでると思われて最適化されちゃうとか無いの?
volatile付けなくても大丈夫?
483:デフォルトの名無しさん
10/10/03 13:45:17
>>482
スレッド間で共有する変数はvolatileつけておくべきだよ。
484:デフォルトの名無しさん
10/10/03 14:19:19
>>483
そんないいかげんな知識で大丈夫か？
485:デフォルトの名無しさん
10/10/03 14:31:25
馬鹿は黙れ。CPUの基本構造も知らずにプログラム組むとか笑えない。
486:デフォルトの名無しさん
10/10/03 14:33:44
>>484
完璧な解説ヨロ
487:デフォルトの名無しさん
10/10/03 14:50:17
ここ読んどけ
URLﾘﾝｸ(d.hatena.ne.jp)
488:デフォルトの名無しさん
10/10/03 14:58:02
>>465
> とはいえ、組み込み向けのバス幅制限があるような環境では
> マルチスレッドはともかく、
> マルチプロセッサ/マルチコアはまずありえないと考えて良いんじゃないかな。
組込み マルチコア でググレばわかるように、もはや組み込みでもマルチ
コアはありえないと言える状況ではないよ。
489:デフォルトの名無しさん
10/10/03 15:10:07
8088やi386SXみたいな内部と外部でバス幅が違うような
石を使わざるを得ない(特殊な？)状況限定の話にそんなレスされても。
490:デフォルトの名無しさん
10/10/03 16:00:49
内部と外部でバス幅が違うなんて組み込みだと今時珍しくないが
もしかしてそんなことも知らんのか？
491:デフォルトの名無しさん
10/10/03 16:58:51
ハードの事わかって書いてるわけじゃないでしょ
最適化されたときのコードの矛盾とかをハードの問題みたいに思ってるのかも
492:デフォルトの名無しさん
10/10/03 19:47:54
【ＯＳ】 Linux,W2K
【言語】 C
【実行環境】Cygwin(W2Kの場合)
【その他特記する事項】 以下の行列演算は高速化できるのでしょうか。
スレッドの意味も作り方もわかりません。
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[j]^=GF[e1[j][i]];
d2[j]^=GF[e2[j][i]];
}
}
493:デフォルトの名無しさん
10/10/03 20:23:30
>>492
それCでコンパイルできた？
494:デフォルトの名無しさん
10/10/03 20:29:53
>>488>>490
「バス幅が違うような環境でマルチコアなんかないだろ？」と
>>465には書かれているように見えるが
おまえ、日本語は苦手か？
両方を満たしたものがめずらしくもないものなら
そう反論しろよ。別個にではなく。
495:デフォルトの名無しさん
10/10/03 20:30:43
>>492
またお前か
496:494
10/10/03 20:38:18
ちょっと書き方を変える。
>>488
「組み込みにマルチコアはありえない」などとは、どこにも書かれてない。
偉そうにしてるが、幻覚でも見たのか？
>>490
「内部と外部でバス幅が違う環境などない」などとは、誰も言ってない。
偉そうにしてるが、電波でも受け取ったか？
「内部と外部でバス幅が違うような用途でも、マルチコアが採用されつつある」
と言いたいのなら、ちゃんとそう書け。
497:デフォルトの名無しさん
10/10/03 22:28:11
> 「組み込みにマルチコアはありえない」などとは、どこにも書かれてない。
⇒ 「マルチプロセッサ/マルチコアはまずありえない」と書いてますが？
＞「内部と外部でバス幅が違う環境などない」などとは、誰も言ってない。
誰もそんなことは言ってないし、誰もそれに反論なんてしてない。
むしろ、最近は珍しくないと書いてあるんだが。
偉そうにしてるが、一体誰と戦ってるんだ？ (w
498: ◆0uxK91AxII
10/10/04 23:01:18
>>484
大丈夫だ、問題無い。
499:デフォルトの名無しさん
10/10/05 22:30:40
>>498
インテルは言っている、素直にインテル・スレッディング・ビルディングブロックを使えと
500:デフォルトの名無しさん
10/10/06 01:31:55
インテルは言っている、インテルはいっている
501:デフォルトの名無しさん
10/10/06 09:05:27
エルシャダイスレはここですか？
502:デフォルトの名無しさん
10/10/06 19:27:08
だめええ！入れないでえええ！インテルいれちゃだめええええええええ！！あ？
503:デフォルトの名無しさん
10/10/06 21:54:44
インテルは逝ってる
504:デフォルトの名無しさん
10/10/10 11:00:31
スタベーションを回避する方法を教えてください。
505:デフォルトの名無しさん
10/10/12 15:22:11
待ち行列の先頭にいるスレッド以外は偶然入れても待ち行列の最後に並んで前の人が終わるまで待つとか
506:デフォルトの名無しさん
10/10/12 20:17:24
>>504
Ａ，Ｂ，Ｃというセマフォを取得するときどのスレッドもＡ，Ｂ，Ｃの順でセマフォを取得する。
507:デフォルトの名無しさん
10/10/13 01:49:19
【ＯＳ】WindowsXP
【言語】C++,Win32
【実行環境】VisualStudio2005
かなり基本的な質問です。
スレッドを外部から終了させたい場合、どのようにすればいいのでしょうか？
あるスレッドを常に動かしていて、ユーザーがGUIプログラムを閉じた場合に、メインスレッド側からどのように命令すればいいのかわかりません。
URLﾘﾝｸ(msdn.microsoft.com)
↑のようなページやググって調べると、スレッド関数側が自発的に_endthreadex関数などで終了する例はあるのですが、
終了するタイミングをスレッド関数側が知らない場合についてはあまり書かれていません。
よろしくお願いします。
508:デフォルトの名無しさん
10/10/13 02:06:21
終了するタイミングをスレッド関数側に教える仕組みがいくつかある
509:デフォルトの名無しさん
10/10/13 06:37:16
>>507
何とかしてサブスレッドに終了を伝える方法を自分で実装する。特に関数はない。
Windowsならvolatile boolかCreateEvent+SetEventでいいだろう。
510:デフォルトの名無しさん
10/10/14 04:23:26
いいか、お前らTerminateThreadは使うなよ！使うな！絶対に使うなよ！
511:デフォルトの名無しさん
10/10/14 07:47:26
kill -KILLですね、わかります。
512:デフォルトの名無しさん
10/10/14 22:51:22
TerminateThread = ハングしろ に近いからねぇ
.Netとかだとそもそも抹消されてるが。Suspendも割と個人的に怖いな
513:デフォルトの名無しさん
10/10/14 22:52:08
TerminateThreadに頼ったプログラムは死んでいいけど、
バグがあってサブスレッドが応答しなくなった時の万が一のためにTerminateThreadするのは
いーんでないの
514:デフォルトの名無しさん
10/10/14 23:08:49
つーかスレッドの終了待ちでWaitFor*Objectしてタイムアウトしたら
TerminateThreadってのは普通だろ
515:デフォルトの名無しさん
10/10/14 23:23:24
そりはバグなので速やかにアプリケーションを終了すべきでは？
少なくとも普通じゃない。
516:デフォルトの名無しさん
10/10/14 23:43:40
>>510
別に使っても問題ないよ。
DllMainのデタッチスレッドさえちゃんと実装されていれば何も問題はない。
517:デフォルトの名無しさん
10/10/14 23:58:39
Vistaより前がターゲットに入るなら「何も問題ない」は無いわ
DllMainがどう頑張ろうと関係無い
518:デフォルトの名無しさん
10/10/15 00:15:38
>>516
DllMainはコールバックされないってちゃんと書いてあるのにどういうコードを書くつもりなのか聞きたい
519: ◆0uxK91AxII
10/10/15 04:13:54
TerminateThreadするくらいならExitProcessで止めを刺す。
520:デフォルトの名無しさん
10/10/15 04:18:38
TerminateThreadなんて使う必要性あるの？
521:デフォルトの名無しさん
10/10/15 06:53:29
サブスレッドの確保したメモリとかソケットとかDB接続とかその他もろもろのハンドル
はどうするつもりだよ。
あとミューテックスをロックしたまま暴走した場合とか開放されるんだっけ？
問題ありすぎ
522:デフォルトの名無しさん
10/10/15 23:13:04
>>514
ないない
523:デフォルトの名無しさん
10/10/15 23:13:49
>>519
そのほうがごみが残らなくていいな
524:デフォルトの名無しさん
10/12/19 17:17:41
printfはどういうレベルでスレッドセーフじゃないんでしょうか
525:デフォルトの名無しさん
10/12/19 17:19:00
間違えた、sprintfです
526:デフォルトの名無しさん
10/12/19 17:22:56
書込み先のことかな？
527:デフォルトの名無しさん
10/12/19 17:24:15
処理系によるんじゃないでしょうか
528:デフォルトの名無しさん
10/12/19 17:30:04
MT-Safe ってどういう意味？
529:デフォルトの名無しさん
10/12/19 17:30:49
複数のスレッドで安全という意味
530:デフォルトの名無しさん
10/12/19 17:32:51
>>527
POSIXというか、ぶっちゃけLinuxの標準ライブラリstdioでならどうでしょうか。
ここまで範囲限定したらスレチになんのかな？
531:デフォルトの名無しさん
10/12/19 17:35:10
POSIXのstdioで _unlocked が付いてないものはスレッドセーフです
532:デフォルトの名無しさん
10/12/19 19:46:28
つまりprintfはスレッドセーフってことか。ありがとう！
533:デフォルトの名無しさん
10/12/19 21:15:28
関数がってことで、使い方間違えると...
534:デフォルトの名無しさん
10/12/19 23:13:56
まぁ想像するだけでもprintfは外部に出力するからロックとか色々してるのは分かる
printfしたらバグが起こらなくなったとかで原因がスレッド絡みとかよくある
んでprintfで起こらなくなるから放置とかマジ勘弁してくださいorz
535:デフォルトの名無しさん
10/12/24 00:47:37
スレッドセーフなメモリの読み書きについて勉強しているのですが、情報が少なく捗りません。
メモリへの同時アクセスによるデータ破壊は、書き込み時にのみ起こると認識しているのですが、正しいでしょうか？
・二つのスレッドが一つの変数を書き換えるとき
→データが破壊される場合がある。
・一つのスレッドが一つの変数を書き換え、別のスレッドがその変数を読み込むとき
→書き込みは問題なく行われる。
→読み込みは、書き換え途中のデータを読み込む場合がある。
・二つのスレッドが一つの変数を読み込むとき
→問題なし。
536:デフォルトの名無しさん
10/12/24 01:06:26
書き込まないものを読み込むことにどんな意味があるのだろうか
537:デフォルトの名無しさん
10/12/24 01:10:53
const 定数ですね
538:デフォルトの名無しさん
10/12/24 01:43:18
>>535
いずれも正しい。
539:デフォルトの名無しさん
10/12/24 06:02:20
ありがとうございます。理解が深まりました。
540:デフォルトの名無しさん
10/12/24 09:17:21
>>535
> ・二つのスレッドが一つの変数を書き換えるとき
> →データが破壊される場合がある。
データの破壊とは何ぞや？単に後から書いたデータが残る。それだけの話。
541:デフォルトの名無しさん
10/12/24 09:53:16
それぞれの書き込みがアトミックならね。
32ビットマシンで64ビットの書き込みとか、アトミックでない場合、破壊が起こるかもしれない。
542:デフォルトの名無しさん
10/12/24 15:07:31
>>540
配列だって、立派な配列変数だぜ。
文字列型変数もあるしな。
543:540
10/12/24 15:52:35
そうだった、最近のデータはでかいんだな。
組み込み系のスレ見た後だったから頭がアセンブラレベルになってた。
失礼。
俺はどっちにしてもミューテックスかクリティカルセクションで排他しておくけど。
544:デフォルトの名無しさん
10/12/24 17:17:54
同時アクセス時の挙動なんてCPUの仕様次第だろ
同時読込なら安全なんて確証は無い
545:デフォルトの名無しさん
10/12/24 17:20:04
データが小さければ読み書きのキャッシュ問題とか無視できるが、
今はふつうに扱う標準データが大きいからなあ。プログラミングも大変だ。
546:デフォルトの名無しさん
10/12/24 17:20:27
アホ発見
547:デフォルトの名無しさん
10/12/24 17:30:42
同時読込なら安全なんて確証は無い・・・
ということは同じ関数を同時に実行するとまずい場合があるってことか
同じ関数を同時に実行すると同じ命令列を同時に読込むことになるもんな
548:デフォルトの名無しさん
10/12/25 20:23:56
言語仕様じゃなくハードウェア仕様だと理解してればいい
大丈夫かどうかを言語仕様で調べても守備範囲外のことで規定されてないから無駄
549:デフォルトの名無しさん
10/12/25 20:28:39
いや失礼、言語仕様で規定されてる物もあるか
550:デフォルトの名無しさん
10/12/26 16:17:56
printfがスレッドセーフじゃないのはわかるけど
どうしてsprintfがスレッドセーフではないのはなぜ？
551:デフォルトの名無しさん
10/12/26 16:24:32
>>550
内部にスタテックバッファーを持ってるかも。
552:デフォルトの名無しさん
10/12/26 16:54:42
>>551
まじか・・・だらしのないやつだなsprintfも・・・
553:デフォルトの名無しさん
10/12/26 17:45:40
おまえが使ってるライブラリを実装したところに聞けよ
554:デフォルトの名無しさん
10/12/26 18:09:36
sprintfがスレッドアンセーフってのはどこ情報？
555:デフォルトの名無しさん
10/12/26 19:50:50
あとだしで申し訳ないがライブラリはglibcです
>>554
URLﾘﾝｸ(slashcolon.com)
URLﾘﾝｸ(www.kmonos.net)
Dでスレッドセーフにしました＝Cだとスレッドセーフちがう
と解釈しました
ていうか、そもそもprintfがスレッドセーフだという情報がない。
不明なうちはアンセーフ扱いするのが俺のジャスティス
556:デフォルトの名無しさん
10/12/26 20:00:44
なるほど
確かに
557:デフォルトの名無しさん
10/12/26 20:13:26
それ英語版見たらスレッドセーフなんてどこにも書いてないぞ・・・
> writefln() improves on printf() by being type-aware and type-safe:
誤訳じゃないのか
558:デフォルトの名無しさん
10/12/26 20:16:54
URLﾘﾝｸ(stackoverflow.com)
適当にぐぐったけどglibcはスレッドセーフとか書いてるような感じ
559:デフォルトの名無しさん
10/12/27 11:09:50
へえ
560:デフォルトの名無しさん
10/12/27 14:34:33
探しても「セーフだろう」「たぶんセーフ」ばっかりしか出てこない
むずむずするなぁ
561:デフォルトの名無しさん
10/12/27 15:03:50
IEEE Std 1003.1-2001の定義では、例外的にアンセーフで良いとされているもの以外は
スレッドセーフ。
URLﾘﾝｸ(pubs.opengroup.org)
562:デフォルトの名無しさん
10/12/28 19:19:26
過去スレ全部はみれなかったんだけど、マルチスレッド関連の良書をまとめてみる。
この他にこれがいいとかあったり、これ駄目とかあったら教えて。
[一般]
並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング
The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで
増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
[java]
Javaスレッドプログラミング―並列オブジェクト指向プログラミングの設計原理 (OO SELECTION)
Concurrency: State Models and Java Programs 2edition
Java並行処理プログラミング ―その「基盤」と「最新API」を究める
[windows]
Win32 マルチスレッド プログラミング
Advanced Windows 第5版 上
Advanced Windows 第5版 下
[Unix]
POSIXスレッドプログラミング
563:デフォルトの名無しさん
10/12/31 19:52:51
[C++]
インテルスレッディング・ビルディング・ブロック
主にこのライブラリの使い方だが、
他にもスレッド管理の考え方が載ってる。まぁオープンソースなので見れるのだけど
564:デフォルトの名無しさん
11/01/03 21:56:27
ありがとうございます。C++の良書をあまり知らないので助かります。
565:デフォルトの名無しさん
11/01/15 09:14:58
concurrent hashmapのC++実装って
なんでないの？
566:デフォルトの名無しさん
11/01/15 09:49:16
>>565
キミのためにお取り置きしてある。
567:デフォルトの名無しさん
11/01/15 10:31:02
>>566
並列mapでいいから実装ないの？
C++って並列コンテナないから何もできないよね
568:デフォルトの名無しさん
11/01/15 18:21:33
>>567
キミが作るだろうと思って残しておいた。
569:デフォルトの名無しさん
11/01/16 11:14:37
>>567
俺のところにはある。
570:デフォルトの名無しさん
11/01/16 11:28:44
C/C++はアセンブラと高級言語の間みたいな位置だからな
言語そのものを作るとか、OSを作るとか、リソースの厳しい組み込み系で作るとか、
そういう用途じゃないなら別に強力な言語ではない
ネイティブのCPUの挙動を理解しないとC/C++の有用性は半減すると思われ
571:デフォルトの名無しさん
11/01/25 23:02:03
すみません、spin-lockをしている間にCPUの使用率を下げる方法を知っている方はいますか？
調べてみると、rep;nop命令やSSEのpause命令をがそれに該当するように思えるのですが、
使ってみても何ら変わりませんでした。
スピンロックつかっわないとは思うんだけど。
自作のスレッドバリア関数（自作のspin_lock）を作って、
たとえば、
if(threadnum=5) sleep(10);
my_barirrer();
とするとスレッド5を待っている間は5以外のCPU使用率が100%近くなってしまいます。
それに対してOpenMP使った場合では、
if(threadnum=5) sleep(10);
#paragma omp barirrer
だと待っている間はCPU使用率は殆ど変わりません。
ちなみに自作のspinlockは下記のような感じです。
if(thread_num == 0)
{
asm volatile(
"Loop1:\n\t\t"
"movl (%0), %%eax\n\t\t"
"movl (%1), %%ebx\n\t\t"
"lfence\n\t\t"
"cmpl %%ebx, %%eax\n\t\t"
"rep;nop\n\t\t"
"jne Loop1\n\t\t"
:
:"r"(&lock->sync), "r"(&lock->maxthreads)
:"memory","%eax","%ebx"
);
というか、これって間抜けですかね？
572:デフォルトの名無しさん
11/01/25 23:10:46
自前でタスク切換えみたいなことするしか
573:デフォルトの名無しさん
11/01/25 23:15:42
>>571
>>369
574:デフォルトの名無しさん
11/01/25 23:24:51
>>573
お前友達いないだろ
575:デフォルトの名無しさん
11/01/25 23:34:47
>>571
Sleepさせりゃいいんじゃね。
576:デフォルトの名無しさん
11/01/25 23:44:45
割り込みでしか切り替わらないコードで使用率下げたいというのが
577:デフォルトの名無しさん
11/01/28 22:22:30
さむいな(´･ω･`)
578:デフォルトの名無しさん
11/01/28 22:43:23
寒稲
579:デフォルトの名無しさん
11/01/31 22:10:29
>>571
CPU使用率が100%じゃないロックなんて、スピンロックとは認めない。
580:デフォルトの名無しさん
11/02/01 00:53:40
そもそも100%じゃないってことはコンテキストスイッチしてるってことになるでしょ？
何のためのスピンロックなのよあり得ない。
581:デフォルトの名無しさん
11/02/01 10:50:42
スリープロックのループもスピン扱いすることもあるから何とも
582:デフォルトの名無しさん
11/04/04 19:37:25.20
ちょっと聞いていい？
以下のコードでnotifyAllされたらどうなるのって質問
void A()
synchronized(Lock){
if(List.size() == 0){
try{ Lock.wait(); }(Exception e){}
}
//以下処理続く
}
}
このコードで複数のスレッドが待ち状態だったらnotifyAllとき再度Lockを取りに行ってくれるの？
もし、そうだったとしたら。
結局はnotifyで１つのスレッドのみ動かすってのと同じことになるの？
それとも再起処理的に以下のようにしなきゃだめ？
void A()
synchronized(Lock){
if(List.size() == 0){
try{ Lock.wait(); }(Exception e){}
A(); ←ここでさらに再帰的に同じメソッドを呼び出す
}
//以下処理続く
}
}
おしえてエロイひと。。。
583:デフォルトの名無しさん
11/04/04 19:47:38.94
>>582
notifyAll を呼ぶと、wait してたスレッドはすべて起きて、 Lock を取りに行く
どうせみんなすぐには取れないから Lock 待ち状態になるが、すでに wait からは外れてるので、 Lock を取れた順にすべてのスレッドが動き出す
notify の場合は、wait してたスレッドのうちひとつだけが起きて Lock を取りに行く
他のスレッドは、その後 Lock が空いても、眠ったまま起きない
wait はふつう再帰じゃなくて while にする
synchronized (Lock) {
while (List.size() == 0) {
Lock.wait();
}
}
waitは、notifyされてなくても間違って起きることがあるらしいので、このように書くべきこととされている
584:デフォルトの名無しさん
11/04/04 20:17:38.60
>notifyAll を呼ぶと、wait してたスレッドはすべて起きて、 Lock を取りに行く
ということはnotifyAllでそのまま下に処理が流れていくんじゃなくて
再度 synchronized(Lock){ ←この部分に処理が戻ってくるイメージなんですかね？
別のメソッド内の以下のようなコードでnotifyAllをかけようと思ってたんだけど、
ちゃんとnumの個数分以上のスレッドは再度、wait状態に入ってくれるのか心配でした
for(int i = 0 ; i < num ; i++){
List.add(object);
}
Lock.notifyAll();
それと。
while (List.size() == 0) {
Lock.wait();
}
これしなきゃいけないんですね。Javadoc見てきました。
>>583 ありがとー。
585:デフォルトの名無しさん
11/04/04 21:55:04.24
>>584
synchronized のところまで戻るわけじゃなく、synchronized の中にいるまま、 wait のところで、
Lock をいったん解放、おやすみなサイして、起きたら元通りに取りにいく
wait は synchronized の中でありながら Lock を手放している特殊な場所
notifyAll を呼んだ側のスレッドは、notifyAll を呼んだあとそのまま下に流れていく
というのも、notifyAll を呼んだ時点では Lock は notifyAll 側のスレッドが握ってるので (synchronized 中のはず)、
wait 側のスレッドは起きるけれども、Lock を取れない
notifyAll 側が synchronized から抜けるなりして Lock を解放すると、wait 側が Lock を取って動き出せるようになる
586:デフォルトの名無しさん
11/05/25 01:36:55.92
質問です
CreateThreadで複数のスレッドを作ったときに渡したパラメータは
スレッドごとに別々のものを渡してもいずれ同じものに書き換えられてしまうと思うんですけど
これをスレッドごとに別々のままにしてやるにはどうしたらいいのでしょうか
VCなら__declspec(thread)をつけるとTLSが使えると読んだのですが
これをCreateThreadに渡すThreadProcのどこで使えばいいのかわかりません
587:デフォルトの名無しさん
11/05/25 03:14:14.44
>いずれ同じものに書き換えられてしまう
そういうことをやってるだけでしょ
588:デフォルトの名無しさん
11/05/25 08:33:13.11
>>586
お前がやってんのは
int a;
int* b = &a;
int* c = &a;
int* d = &a;
のb,c,dが別々のものと言ってるのと同じだろ
589:デフォルトの名無しさん
11/05/25 08:38:22.51
あーなるほど、同じ場所(=ポイント先)を渡して「別々のもの」と言い張っているのか。
590:デフォルトの名無しさん
11/05/25 11:41:30.98
forkってスレッドセーフ？
591:デフォルトの名無しさん
11/05/25 11:56:15.17
>>590
関数だけ見ればMT-safe
URLﾘﾝｸ(pubs.opengroup.org)
でも
URLﾘﾝｸ(d.hatena.ne.jp)
592:デフォルトの名無しさん
11/05/25 21:24:18.36
別のポインタ渡したつもりで同じものを渡していたことに気づいて悲しくなりました
お手数おかけしました
593:デフォルトの名無しさん
11/06/23 08:39:51.24
スレッドって、毎秒ごとに数百回の開始と終了を繰り返すような使い方は正しいの？
それとも、必要な時だけスレを立てる使い方じゃなくて、
スレは基本的に立てっぱにしといて、用がある時にメッセージ等を送るという使い方をすべき？
594:デフォルトの名無しさん
11/06/23 08:45:48.47
スレッドの開始はそれなりにコストの大きい処理だから
スレッドプールにするのが正解
595:デフォルトの名無しさん
11/06/23 08:49:17.54
なるほど。直観的じゃないのな。
596:デフォルトの名無しさん
11/06/23 09:10:49.87
用途によるよ。一度スレッドを起動したら数十秒は戻ってこないならプールしなくても大差ない。
597:デフォルトの名無しさん
11/06/23 09:47:04.06
593の前提と変わってるじゃんか
598:デフォルトの名無しさん
11/06/23 22:41:08.11
>>593
同時に起動できるスレッドの数ってそんなに多くないしな。
32bit、Windowsだと2000個くらい(スタックサイズ標準の場合)
599:デフォルトの名無しさん
11/06/24 00:22:34.83
スレッドの生成は5ミリ秒くらいのオーバーヘッドあるだろ。
数百回やるなんて頭おかしい
>>598
今時32ビット縛りなんて考える必要なくね？
600:デフォルトの名無しさん
11/06/24 05:23:53.79
5msec!
601:デフォルトの名無しさん
11/06/24 10:49:09.11
なにそのみずほ銀行
602:デフォルトの名無しさん
11/06/24 10:53:32.07
ミリ秒はつらいな・・・
と思ったけど16ビット機なら仕方ないか。
603: ◆0uxK91AxII
11/06/24 17:27:33.68
手元の環境だと、threadの生成と実行開始のどちらも0.1[ms]すら掛からないね:)
604:デフォルトの名無しさん
11/06/25 01:58:06.76
XPからスレッド生成が凄く速くなった記憶がある
605:デフォルトの名無しさん
11/06/25 17:22:00.98
じゃあ0.1msでスレッド生成するコード晒してみろよ
606: ◆0uxK91AxII
11/06/25 18:39:30.70
Win32のCRTにある_beginthread。
生成は0.1[ms]未満、実行開始はコンパイラかライブラリに依存で0.1[ms]台からに訂正。
#include <Windows.h>
#include <stdio.h>
#include <process.h>
struct perf {LARGE_INTEGER freq;LARGE_INTEGER t0;};void __cdecl thread(void *
pArg){perf *pperf;LARGE_INTEGER t1, d;QueryPerformanceCounter(&t1);pperf = (perf
*)pArg;printf("thread: %I64d\n",t1.QuadPart-pperf->t0.QuadPart);}int main(){
LARGE_INTEGER f={0}, t0, t1, d;perf perf;QueryPerformanceFrequency(&f);printf(
"freq: %I64d\n", f.QuadPart);perf.freq = f;QueryPerformanceCounter(&t0);perf.t0
= t0;_beginthread(thread, 0, &perf);QueryPerformanceCounter(&t1);printf(
"main: %I64d\n", t1.QuadPart-t0.QuadPart);Sleep(1000);return 0;}
607:デフォルトの名無しさん
11/06/25 22:55:22.93
>>606
5764ticks/272758=2.1ms。
一桁違ってないか？どんだけ速いマシン使ってんの
608:607
11/06/25 23:17:06.14
訂正。
誤:5764ticks/272758=2.1ms
正:5764ticks/2727568=2.1ms
処理のスループットが問題なんだからJOINの時間も入れよーぜ。
あと、>>606はmainが先に終わると不正メモリアクセスになる糞コード
609:デフォルトの名無しさん
11/06/26 01:54:34.21
C#だけど2マイクロ秒くらいだよ。
var sw = new System.Diagnostics.Stopwatch();
sw.Start();
for (var i = 0; i < 1000; i++) {new Thread(F);}
decimal time = (decimal)sw.ElapsedTicks / System.Diagnostics.Stopwatch.Frequency;
Console.WriteLine("{0} [ms]", time / 1000 * 1000);
610:デフォルトの名無しさん
11/06/26 02:04:01.25
∩＿
〈〈〈 ヽ
〈⊃ }
∩＿＿＿∩ | |
| ノ ヽ ! !
/ ● ● | /
| ( _●_) ミ／ こいつ最高にアホ
彡､ |∪| ／
/ ＿＿ ヽノ /
(＿＿＿） /
611: ◆0uxK91AxII
11/06/26 10:35:46.17
>>607 >>608
Core i7 2600K 3.4[GHz] HTT無効, Windows 7 X64 SP1, Visual C++ 2010 Express
＞mainが先に終わると不正メモリアクセスになる糞コード
大丈夫だ、問題ない。
>>609
thread poolだから略。
612:デフォルトの名無しさん
11/06/26 15:21:14.56
＞mainが先に終わると不正メモリアクセスになる糞コード
こういうことを平気で書いちゃう人もいるんだな。笑える。
613:デフォルトの名無しさん
11/06/26 15:23:47.45
具体的に反論できない奴のテンプレート的反応で笑える。
614:デフォルトの名無しさん
11/06/26 20:09:29.64
>>611
Xeon E5506 2.13GHzだが0.46msだった。0.1msには及ばない。
>thread poolだから略。
Threadはスレッドプーリングされない。単にStartし忘れているだけ
615:デフォルトの名無しさん
11/06/26 22:10:05.48
node.jsの説明見ているとシングルスレッドなので万歳！みたいな記事が多く混乱してみる
616:デフォルトの名無しさん
11/06/26 23:27:19.63
あれは
『マルチスレッドやマルチプロセスではC10Kに対応できなくね?
俺良い事思い付いた。シングルスレッドでイベントドリブンにしたら良いんじゃね。』
という発想だから、
『あー、でもマルチコアマシンではシングルスレッドだと性能出なくね?
結局ロードバランサとか必須だわな。』
みたいな話をすると、そもそも何でマルチスレッドを否定していたのかという
自己矛盾に陥るので、わざとスルーしているのかもね。ちょっと分かり辛いよね。
617:デフォルトの名無しさん
11/06/26 23:49:28.20
C10Kが騒がれてたのはもう10年くらい前の話で、
その頃は1CPUでシングルコアのマシンが殆どだったしね
618:58-3-155-112.ppp.bbiq.jp
11/06/27 07:39:41.06
リクエスト来る事にスレッド作成してた今までが異常すぎ
C10K問題で破綻するのは今でも一緒ですわい
619: ◆0uxK91AxII
11/06/27 09:16:36.96
>>614
＞Threadはスレッドプーリングされない。単にStartし忘れているだけ
ouch
C#、試してみたら遅すぎた。
Cの4~20倍くらい掛かっている。
620:デフォルトの名無しさん
11/06/27 19:42:02.22
>遅すぎた
0.1msの20倍は2msだろ。
50スレッド生成しても0.1秒、全く問題ないような
621:デフォルトの名無しさん
11/06/27 20:02:07.59
Unix屋なんでWindowsは全く詳しくないけど
スレッド数をむやみやたらを増やしてもオーバーヘッドが多くなるだけでいいことなんてないのでは？
それよりスレッドプールを使った方が管理も簡単だと思うんだけど、Winの開発環境にはもしかしたら
スレッドプールライブラリーみたいなのがなくて自分で仕組みを作らなきゃ駄目なのかい
622:デフォルトの名無しさん
11/06/27 20:04:40.67
スレッドは設計？をよう考えないとハマるだろうに
623:デフォルトの名無しさん
11/06/27 21:44:24.18
>>621
UNIXでよく使われるものはWindowsにもある
と考えてまず間違いない
624:デフォルトの名無しさん
11/06/27 23:29:57.24
スレッドのメリットはスループット性能だけではないのだが。
625:デフォルトの名無しさん
11/06/28 10:33:59.70
メモリ空間が共通なのはデメリットだよね？
626:デフォルトの名無しさん
11/06/28 11:04:08.15
共通じゃないのが欲しければfork→execでいいんじゃね。
627:デフォルトの名無しさん
11/06/28 20:31:14.09
メモリ空間共通のデメリットって、Cでメモリ破壊の危険性を排除できない
ぐらいしか思いつかないんだが。
628:デフォルトの名無しさん
11/06/28 20:40:04.57
・メモリ共有だと、プロセスが落ちたら皆落ちる
・NUMAではメモリ上のデータは分散していた方が良いよね?
・別プロセスなら別ノードにも移せるので自由度が高い
・セキュリティ（他の実行単位からデータが見えない）
等々
629:デフォルトの名無しさん
11/06/28 20:43:17.24
仕事で4Gの空間じゃ足りないってことがあった
64bitならしらねｗ
630:デフォルトの名無しさん
11/06/28 20:55:56.81
NUMAは違うだろ
どこから割り当てるかは別にプロセス分けなくてもできる
631:デフォルトの名無しさん
11/06/28 21:36:49.16
メモリ空間が共通なのはメリットだろう常考
632:デフォルトの名無しさん
11/06/29 10:48:43.16
プログラムは常に死ぬ可能性がある という前提に立つと、
メモリ空間の共有はデメリットだよな
633:デフォルトの名無しさん
11/06/29 11:36:26.30
メリットもデメリットもある
634:デフォルトの名無しさん
11/06/29 11:51:59.86
>>632
>プログラムは常に死ぬ可能性がある という前提に立つと、
なんという時代遅れのやつ
635:デフォルトの名無しさん
11/06/29 12:05:00.86
スレッド蹴るかプロセス上げるかは、利用場面での損得勘定で決まることだから、
状況想定もなしにメリットデメリットを語ってもナンセンスすぎてなあ…
636:デフォルトの名無しさん
11/06/29 12:54:18.84
>>635
マルチスレッドで得られるメリットは基本的にパフォーマンスのみ。
マルチプロセスで得られるメリットはマルチスレッドで実現不能なことがほとんど。
637:デフォルトの名無しさん
11/06/29 16:52:22.47
ある特徴が長所なのか短所なのかは目的次第（この話に限らない一般論）
パフォーマンスいらないならマルチスレッドなんてしないだろ
638:デフォルトの名無しさん
11/07/23 20:17:54.60
処理中にUIが固まらないようにするためのマルチスレッドは
よく使用されるが、それをパフォーマンス目的とは言わないだろう
639:デフォルトの名無しさん
11/08/02 16:21:14.65
パフォーマンスだけがメリットだとしても、パフォーマンスのメリットは計り知れない
からな
クラしか見てない奴はパフォーマンス需要は頭打ちと思ってるかもしれんが、鯖は逆に
クラウド化でクラの負担も全部引き受ける路線だから、パフォーマンスが非常に厳しく
求められるようになってる訳だし、鯖向けソフトウェアはパフォーマンス一つでシェア
が取れる例も全く珍しくないしな
640:デフォルトの名無しさん
11/08/02 16:23:33.58
×クラウド化で
○クラウド化とか含めて
641:デフォルトの名無しさん
11/08/14 09:56:51.34
>>638
例が適切ではｱﾘﾏｾﾝﾈｰ
UIを固めない = 操作者を待たせない = 操作者も含めたシステム全体のパフォーマンス向上、
という図式が成立するとも言う
パフォーマンス向上以外のマルチスレッド利用としては、
非同期事象を取りこぼさずに受けるため、というのが挙げられると思うが、
それとて取りこぼさずに済むためのハードウェアの速度要件もしくはCPU時間消費の低減につながるため
結果的にパフォーマンス向上と言えなくもないという、
642:デフォルトの名無しさん
11/08/14 12:36:09.51
URLﾘﾝｸ(msdn.microsoft.com)
これでおk
643:デフォルトの名無しさん
11/08/14 13:42:20.18
>>641
副次的な効果を目的に持ってこないほうがいい。
UIを固めないと中断が実現できたり、操作者のわかりやすさに繋がるんだよ。
それはパフォーマンス向上ではなく、別のことが目的だろう。
644:デフォルトの名無しさん
11/08/14 13:58:19.75
>>643
例えばIDEがエディタを固まらせないでバックグラウンドでソースを解析するのは
>操作者も含めたシステム全体のパフォーマンス向上、
になるんじゃないの?
645:デフォルトの名無しさん
11/08/15 02:52:00.24
>>644
よく読めよ。
>>638が噛みついたのは「処理スレッドをUIと別にするのがパフォーマンス目的か？」
じゃなくて、
「マルチスレッドは必ずパフォーマンスが目的と言えるのか？」だろ。んなこたーない
646:デフォルトの名無しさん
11/08/17 12:42:20.68
>UIを固めないと中断が実現できたり、操作者のわかりやすさに繋がるんだよ。
これをパフォーマンス向上と言ってもおかしくない
URLﾘﾝｸ(dic.yahoo.co.jp)
647:デフォルトの名無しさん
11/08/17 18:54:09.83
>>646
どこを読めば良いのでしょうか
648:デフォルトの名無しさん
11/08/17 19:21:06.24
うーん・・
ことプログラミングの文脈に関する限りはユーザーリスポンシビリティやユーザーエクスペリエンス
はパフォーマンスの一部と解釈することはあまり無いんじゃないかな?
649:デフォルトの名無しさん
11/08/17 20:51:02.93
>>646
おかしい
650:デフォルトの名無しさん
11/08/21 09:04:32.75
「パフォーマンスの向上」が何を意味するのか、が決まらないと無意味な議論だな
その点に限れば、主観以外の論拠が出てこない（実際出てない）から、終着点なんか
無いぞ
元々MTのメリットという話題だったが、技術的に何の参考にもならん話だしどうでも
いいんだが
651: ◆0uxK91AxII
11/08/21 11:45:37.53
意味を定義しても無駄な議論だけどね:b
652:デフォルトの名無しさん
11/09/09 19:42:55.52
Ｃ＃のマルチスレッドのプログラミングです。
変数がいくつかある。例えばこんな感じ。
int A;
int B;
・
・
int Z;
で、スレッド①で定期的にA～Zの変数の値を更新している。
スレッド②からこれら変数を読みたいのだが、必ずA～Zまで全部更新された状態で読みたい。
（つまりスレ①が更新処理中に読みに行くのはアウトってこと。）
優先度が高いのはスレ①です。
どうやれば“スマート”なんでしょう？
変数を更新している間スレ①以外の実行を止めるような仕掛けがあるんじゃないかと思って探したんだけど無さそうだね。
653:デフォルトの名無しさん
11/09/09 19:50:28.24
URLﾘﾝｸ(ufcpp.net)
654:デフォルトの名無しさん
11/09/09 20:10:35.64
>>653
それ、なんかちゃうで。
655:デフォルトの名無しさん
11/09/09 21:29:06.03
>>652
途中で読まれてはいけない更新の開始から最後までロックする。
ロックが長時間にわたる可能性がある場合はSystem.Threading.Mutex.WaitOneで
タイムアウトさせる。
656:デフォルトの名無しさん
11/09/09 21:57:27.33
1以外は読むだけなんだろ？
そりゃ System.Threading.ReaderWriterLock だろ
657:デフォルトの名無しさん
11/09/12 00:26:16.03
中途半端な状態で読むのがアウトってだけだったら、一つのクラスにA～Zの変数をまとめておいて
更新時には丸ごと新しいインスタンスに差し替えてしまえばロックいらないよ
658:デフォルトの名無しさん
11/09/13 18:08:55.63
RCUのめんどいところは古い情報をいつ削除するか
659:デフォルトの名無しさん
11/09/14 18:37:15.35
C#での話だからGC任せでok
あと、インスタンスへの参照を保持する変数にはvolatileを付けとけよ。
660:デフォルトの名無しさん
11/09/14 21:28:32.04
この使い方だと実はつけなくても大丈夫だけどな。
つけとく方がいいけど。
661:デフォルトの名無しさん
11/09/14 22:13:31.15
クライアントが古い方への参照を持ち続けていてはまると予想。
662:デフォルトの名無しさん
11/09/15 00:00:30.87
>661 の他にも、「新インスタンス上の変数A��Zへの書き込み」と
「共有変数を新インスタンスへの参照で更新」がリオーダーされないようにする必要がある。
663:デフォルトの名無しさん
11/09/15 00:24:43.65
.NET Framework 2.0以降（CLR2.0以降）のメモリモデルでは、
書き込み順をリオーダできないというルールがあるため、それは起こらない。
664:デフォルトの名無しさん
11/09/15 02:03:26.35
>>663
一般の変数に関しては、そんな規定は仕様書の何処にもない。
665:デフォルトの名無しさん
11/09/15 02:49:09.91
は？
666:デフォルトの名無しさん
11/09/15 08:20:18.11
コンパイラが順序通りに書き込んでもCPUがそのように
振る舞うわけねーだろ
667:デフォルトの名無しさん
11/09/15 08:23:43.17
メモリモデルの意味も分かってない馬鹿ばかり。
668:デフォルトの名無しさん
11/09/15 08:45:27.59
>>666
お前はMSの文書ちゃんと読めよ
669:デフォルトの名無しさん
11/09/15 09:34:15.77
ちなみに読み込みは順序換えが許されている。
一般的には読み込み順序の問題でvolatileが必要になるんだが、
今回のような処理では、参照変数より先に参照先を読むことが不可能なため、
volatileがなくても実は問題が発生しない。
もちろん読み込みの挿入が許可されてないってのも重要なんだが。
まあ普通はvolatileつけるでOK。
670:デフォルトの名無しさん
11/09/15 10:44:40.93
>>669
いや、だから読み書きともに順序替えが許されてるんだってば
671:デフォルトの名無しさん
11/09/15 11:08:07.18
>>669
つけなくて大丈夫ってことは無いよ
なにか別のパターンと勘違いしてないか？
672:デフォルトの名無しさん
11/09/15 11:27:46.91
つけなきゃだめってのは、何を見て言ってるの？
CLR2.0のメモリモデルでは書き込み順序換えは許可されてない、
かつ読み込みを複数回に分ける事も許可されてない、
したがって今回のような処理では実質的にvolatileは不要。
このことはMSDNマガジンにも書かれてる内容。
673:デフォルトの名無しさん
11/09/15 11:28:52.30
>>670
書き込み順序換えは出来ないとはっきり書かれてる。
674:デフォルトの名無しさん
11/09/15 11:59:15.21
>>673
どこに？
CLIの仕様書にはどこにもそんなことは書かれてないが。
675:デフォルトの名無しさん
11/09/15 12:01:40.73
>>672
それはあんたがMSDNの記事を誤読してるだけだろ。
676:デフォルトの名無しさん
11/09/15 12:08:07.35
>>674
だから最初からCLR2のメモリモデルではと言っとろうに
677:デフォルトの名無しさん
11/09/15 12:13:29.95
>>675
どこを誤読してるのか明確に指摘してくれ。
URLﾘﾝｸ(msdn.microsoft.com)
正確には全く同じ話ではないが、結論は同じことになる話が出てる。
まあMSDNマガジンの例の方がより無茶な話も出てるけど。
678:デフォルトの名無しさん
11/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
11/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:デフォルトの名無しさん
11/09/15 12:32:34.08
>>679
不要。
読み取りを削除出来るのは、同一ロケーションからの隣接した読み取りのみ。
よって読み取りが削除されることはない。
681:デフォルトの名無しさん
11/09/15 12:34:46.76
>>678
ECMAのメモリモデルではあり得るが、
CLR2のメモリモデルでは起こらない。
682:デフォルトの名無しさん
11/09/15 12:57:20.42
>>680
おっと、もう少し正確には、読み取りが丸ごと無くなってしまうような事はない。
683:デフォルトの名無しさん
11/09/15 21:05:03.01
どうでもええけどえらそーに言ってたやつらが急に黙りこくってて笑えるぞ
684:デフォルトの名無しさん
11/09/19 02:54:28.89
>>677
それって、Xbox360のXNAとかWindowsPhoneとかでも同じなのかな。
IA-64版のメモリモデルをx86版とほぼ同じになるように修正したのは
ビジネス的な判断としてはアリかもしれんが、
PowerPCやarmでも同じようにするのはオーバーヘッドが大きすぎると思うんだが。
685:デフォルトの名無しさん
11/09/19 10:38:04.13
実行環境（.NET Framework）の話とC#などの言語の話がごっちゃになってる気がする。
.NET Frameworkのモデルでは書き込み順が入れ替わることはないが、
その前のコンパイラの段階で x = 1; y = 2;が逆転することはある。
686:デフォルトの名無しさん
11/09/19 11:50:25.42
ねーよ。
何のために変わるんだよ。
687:デフォルトの名無しさん
11/09/19 16:23:59.39
まあCLRのメモリモデルを頼りにしたければ、MSILで書けってこった。
688:デフォルトの名無しさん
11/09/19 17:16:22.88
メモリモデルに反するコンパイルを行うコンパイラがどこにあんだよ。
689:デフォルトの名無しさん
11/09/19 18:54:18.85
＼ここにいるぞ！／
690:デフォルトの名無しさん
11/09/19 19:10:50.21
ヒュー！
691:デフォルトの名無しさん
11/09/19 19:37:52.18
ハンドコンパイラ､自由にコードを作成できる
692:デフォルトの名無しさん
11/09/19 20:11:33.77
最近のコンパイラは最適化もしなくなったのか
693:デフォルトの名無しさん
11/09/19 21:18:28.10
「最適化」を「何でもアリ」と勘違いしているヒトが居る模様
694:デフォルトの名無しさん
11/09/19 21:29:41.61
実際問題、最近のマルチスレッドを前提とした中間言語処理系では、
昔みたいな静的コンパイル時の大胆な最適化は行わない。
というか、実行環境のCPUが想定できないので、あまり意味もない。
695:デフォルトの名無しさん
11/09/19 21:36:40.42
もっとも、可能性で言えばECMA仕様準拠のコンパイラならありえなくはない。
MSのコンパイラならあり得ない。
でも多分、ECMA仕様準拠のコンパイラでもそんなことはやらない気がする。
696:デフォルトの名無しさん
11/09/19 22:14:25.39
それこそ言語仕様次第でしょ。
たとえばCプログラムが、逐次一貫性メモリモデルに沿ったプロセッサで動く実行コードに
コンパイルされるとして、じゃあ何が保証されるかというとCの言語仕様の範囲内でしかない。
書き込み順を入れ替えても、Cコンパイラとしては正しい。
697:デフォルトの名無しさん
11/09/19 23:26:17.69
だから最初から特定の処理系の話だよね。
698:デフォルトの名無しさん
11/09/19 23:29:00.91
そして言語仕様だけでは定義されてない範囲ってものがある。
C言語仕様だけじゃマルチスレッドにおいて何もできない。
699:デフォルトの名無しさん
11/09/20 00:11:35.17
結局、>678の質問の答えはどうなん？
CLRの仕様から答えは決まるのか、
それともC#も仕様で決まるのか？
700:デフォルトの名無しさん
11/09/20 00:14:14.83
>699
>698が言ってる通り、C#の仕様では1-4の実行順序は規定されていない。
よって、リオーダーは起こりうる。
701:デフォルトの名無しさん
11/09/20 00:41:04.58
C/C++の仕様だと、;等のシーケンスポイントの前後での入れ替えは
起こらないことが規定されてるけどな。
機械語の書き込み順が、現れた順番で行われるかどうか、という点には
何も規定されていない。JVMやCLR等はそういう点にも言及されていると。
702:デフォルトの名無しさん
11/09/20 00:55:54.52
それはCプログラムの意味（抽象機械上での振る舞い）定義でしかないよ。
意味が変わらなければ入れ替えは許される。
（そうでないと、ループ不変式移動すらできない）
問題は、Cプログラムの意味定義は実行の流れがひとつという前提でなされていること。
703:デフォルトの名無しさん
11/09/20 00:58:37.26
ついでに機械語命令の実行順は、プロセッサの仕様で規定されている。
もちろん未規定な部分もあるけどね。
704:デフォルトの名無しさん
11/09/20 01:14:32.80
？？？
705:デフォルトの名無しさん
11/09/20 01:18:24.02
>問題は、Cプログラムの意味定義は実行の流れがひとつという前提でなされていること。
C#の言語仕様では、別スレッド等ではなく突然実行が複数になったり入れ替わったりすることを許しているわけ？
>ついでに機械語命令の実行順は、プロセッサの仕様で規定されている。
CLRでは規定されてないとでも？
706:デフォルトの名無しさん
11/09/20 01:26:01.83
さっきから暴れてる方、
＞>698が言ってる通り、C#の仕様では1-4の実行順序は規定されていない。
や
＞意味が変わらなければ入れ替えは許される。
の出展を示してくれませんかね。
それぞれ、C#の言語仕様とCの言語仕様の、どの部分で言及されているのか。
でなければ、ただの脳内妄想と区別がつきませんので。
707:デフォルトの名無しさん
11/09/20 01:48:51.52
その通りだと思うが出典だぞ
708:デフォルトの名無しさん
11/09/20 02:28:18.91
C#言語仕様の範囲では、
C#言語仕様の
3.10 実行順序
および
10.5.3 Volatile フィールド
で規定されてる。
でMSの.NET Frameworkの実装としては、何度か出てるCLRの仕様に則っている。
709:デフォルトの名無しさん
11/09/20 08:38:12.37
コンパイラが実行順序かえたら駄目だろ
710:708
11/09/20 09:28:06.57
念のため、俺は>>700ではない。
711:デフォルトの名無しさん
11/09/20 09:28:42.41
レベルひくっ
712:デフォルトの名無しさん
11/09/20 10:22:38.97
○＿＿＿＿
.|| |
.|| ● |
.|| |
.||￣￣￣￣
.|| 君が代は
∧__,,∧|| 千代に八千代に
( ｀･ω･|| さざれ石の巌となりて
ヽ つ０ こけのむすまで
し―-J
713:デフォルトの名無しさん
11/09/23 11:34:40.79
>>708
C#言語仕様もCLRの仕様も、またECMAのCLI仕様においても、
全部「命令のリオーダーが許されるか否か」の視点でしか
記述されてないんだよね。
例えばCLR2.0においては、同一スレッド内の書き込みの順序は
入れ替えられないとされてるようだけど、実行環境がx86であれば
それは単に「コンパイラがプログラムを機械語に落としこむときに
書き込み命令の発行順を入れ替えない」とするだけで実現可能。
x86 CPUのメモリモデルは非常に強いので、アウトオブオーダー実行などによって、
ある書き込みが先行する書き込みより先にglobally visibleになることは認められていない。
714:713
11/09/23 11:35:46.25
でも、PowerPCやarmでは事情が違ってくる。
これらのCPUのメモリモデルはx86よりもずっと緩いので、
単に「コンパイラが書き込みの順序を入れ替えない」とするだけだと、
CPUによるリオーダーによって「他スレッドからは書き込み順が
入れ替わったように見える」ことが起こりうる。
一方で、このようなCPUによるリオーダーまでも防ごうとすると、
ほとんどの書き込み命令の間にメモリバリア命令を挟まなきゃ
ならなくなる。当然、パフォーマンスの低下はとてつもない。
.NETのメモリモデルって、x86のことしか考えてないように見えるんだよね。
JavaやC++11のメモリモデルは、そういう「リオーダー禁止」とかの
直接的視点ではなく、もっとメタなレベルで「ある書き込みが
ある読み込みからはvisibleか否か」を定義してるので、
x86以外のアーキテクチャでも実装しやすくなっている。
今後、マルチコアなWindowsPhoneが出てきたときに
いろいろ酷いことになったりしなきゃいいが。
715:デフォルトの名無しさん
11/09/23 18:44:38.36
実際にitanium版とかあるわけで、実用上なんとかなるレベルだったんじゃないの？
716:デフォルトの名無しさん
11/09/23 18:48:00.72
あとCLIとかのメモリモデルもリオーダはメモリの可視性を含めた話だよ。
キャッシュの影響で、実質的に順序が変わったように見える話とかも出てきてるんだから。
特にECMAの仕様はかなりjavaに近いと思うが。
ていうかほとんどjavaと変わらんような。
717:デフォルトの名無しさん
11/09/23 18:52:07.56
書き込み毎にメモリバリアいるんじゃないかってのは俺も疑問無くはないんだけど、
多くのCPUではこのルールを守るのは大してペナルティはないというのも読んだことがあって、
実際のとこはよく分からない。
718:デフォルトの名無しさん
11/09/23 18:54:03.30
何が言いたいのかわからんなあ
719:! 【14m】 【東電 66.0 %】
11/09/23 18:58:34.31
ペリフェラルいじるときは
エイエイオー
しまくりだ
720: ◆0uxK91AxII
11/09/23 20:02:20.23
CLRなんて作らないから、どうでも良い。
721:デフォルトの名無しさん
11/09/23 22:55:12.81
>>715
Itaniumで.NETアプリを動かすのって、基本的には
x86のWindowsサーバー上のアプリをそのまま持っていきたい
ってニーズがほとんどだろうから、その場合はパフォーマンスより先に
互換性確保のほうが最大限に重視されるだろうね。
722:デフォルトの名無しさん
11/09/24 03:15:05.37
C++0xとCLRとJavaのメモリモデルの違いとか考えたこともない話だわ
マルチスレッドに詳しいひとは普段どんな仕事してるんだろ
723:デフォルトの名無しさん
11/09/24 10:21:23.71
排他に必要なメモリバリア類をライブラリだかCLRだかVMだかがやるんじゃないの。
そこを超えて踏み込む（＝排他をケチる）とメモリモデルの違いが表面化するとか？
俺の持論：volatileで十分ｗ
724:デフォルトの名無しさん
11/09/24 11:58:45.66
volatileの言語仕様知らないだろｗ
725:デフォルトの名無しさん
11/09/24 15:39:38.60
volatileを信用してると痛い目合うコンパイラもあるぞ
726:デフォルトの名無しさん
11/09/24 15:56:04.66
会う
727:デフォルトの名無しさん
11/09/24 17:11:35.69
コンパイラからバールのような物が飛んでくるのですね
728:デフォルトの名無しさん
11/09/24 17:55:34.09
perlのようなものか
729:デフォルトの名無しさん
11/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
11/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:デフォルトの名無しさん
11/09/24 19:22:11.48
.NETではInterlocked使うんだよ
732:デフォルトの名無しさん
11/09/24 20:10:49.35
メモリバリアとアクセス競合ごっちゃになってないか？
733:デフォルトの名無しさん
11/09/25 00:03:40.81
javaってこれのせいでvolatile遅いんじゃねーの？
734:デフォルトの名無しさん
11/09/25 00:21:16.82
Javaって誕生当初はロックのコストが無視できるくらいVM遅かったの?
コレクションが全部同期とか頭おかしいよね
735:デフォルトの名無しさん
11/09/25 00:25:40.60
遅かった
736:デフォルトの名無しさん
11/09/25 01:33:01.66
複数リクエストが並行してバンバン来るservletやjspがその上で動いてたもんだから大変
737:デフォルトの名無しさん
11/09/25 13:00:47.00
>>734
まさにそのとおり
738:デフォルトの名無しさん
11/10/04 11:57:09.05
ハードディスクが一つしかない環境だと
ファイルアクセススレッドを何本走らせても結局ハードディスクにアクセスしてるのは常に一つだから
二本目以後は意味ないですか？
739:デフォルトの名無しさん
11/10/04 13:08:54.15
そんなことはない。
740:デフォルトの名無しさん
11/10/04 15:42:40.84
シークが増えて、余計に遅くなるという意味なら有る
741:デフォルトの名無しさん
11/10/04 18:03:27.80
CPUから見ればI/Oは超遅いから無意味、と予想するけど
OSやHDDのキャッシュでかなり違うのかもしれない
結局環境依存だしやってみて実測するしかないっていうね
742:デフォルトの名無しさん
11/10/04 20:06:08.63
>>738
>>740
シークを待っている間に別の処理を行える事で、
早くなる可能性もある。どっちに転ぶかは仕様
次第なんで、それだけの話じゃわからない。
確実に言えるのは「早くなる場合と、遅くなる場合と、変わらない場合がある」って事だけだ。
743:デフォルトの名無しさん
11/10/04 20:49:34.91
S-ATAて仕様上はコマンド並び替えとかでシーク減るとか無かったけ?
744:デフォルトの名無しさん
11/10/05 10:48:57.34
期待するだけ空しい
745:! 【13.8m】 【東電 78.9 %】
11/10/09 21:31:08.21
NCQをまともに機能させるのは大変なことだお（ ＾ω＾）
746:デフォルトの名無しさん
11/10/10 06:46:41.34
FFのリークが酷過ぎ
747:デフォルトの名無しさん
11/10/19 08:42:15.18
メモリバリアとか難しすぎて頭おかしくなりそう
atomic_int a = 0, b = 0;
//thread1
a.store_acquire(1);
int x = b.load_release();
//thread2
b.store_acquire(1);
int y = a.load_release();
これでx == 0 && y == 0が真になることがあるという話なんだけど頭の中でどう考えてもならない
いったいどういうカラクリでx,yが同時に0になるの？
748:デフォルトの名無しさん
11/10/19 09:23:38.50
>>747
正しくはstore_releaseとload_acquireね。
store & acquire とか、load & release とかいう組み合わせはない。
749:デフォルトの名無しさん
11/10/19 13:56:45.85
>>747
他のスレッドに値が反映されるまでラグがあると考えればいいよ
750:デフォルトの名無しさん
11/10/22 16:08:33.08
>>747
atomic_int a = 0, b = 0;
//thread1
a.store_release(1);
int x = b.load_acquire();
//thread2
b.store_release(1);
int y = a.load_acquire();
だとすると、
load_acquire()はstore_release()の前に移動できる。
751:デフォルトの名無しさん
11/10/22 21:42:35.60
そういやなんで皆ロックの速さに拘るの?
スレッド全体の処理量に対してロックが必要なのは極僅かでしょ。
752:デフォルトの名無しさん
11/10/22 21:55:02.53
いやロックの話じゃなくてアトミック操作の話
753:デフォルトの名無しさん
11/10/22 22:55:15.90
排他ロックしたら負け
754:デフォルトの名無しさん
11/10/23 09:19:45.48
volatileで十分ｗ
755:デフォルトの名無しさん
11/10/23 09:26:02.86
>>754
解雇
756:デフォルトの名無しさん
11/10/23 14:57:53.13
volatileでどんなコード吐くかみんとハマるよ
757:デフォルトの名無しさん
11/10/23 15:13:30.40
javaやC#ならvolatileで充分だろうな。
CとC++のvolatileは別もんだから役に立たん。
詳しくはC++11スレを見てこい。
758:デフォルトの名無しさん
11/10/23 15:22:42.74
volatileかmutexかなんてのはこっちでする話だろうに
なんであのスレでしつこく長引いてたんだか
759:デフォルトの名無しさん
11/10/23 16:16:29.85
>>758
言語仕様読まないバカが粘着したせい
760:デフォルトの名無しさん
11/10/23 19:18:18.55
C/C++のvolatileはvolatileで目的があって用意されたものだがマルチスレッドと直接関係はない低水準機能で、
使う場合もあれば使わない場合もあると。
volatile std::atomic<T>はJavaのvolatileとほぼ同じ意味だそうだが。
761:デフォルトの名無しさん
11/10/23 19:28:17.70
コンパイラによる静的な省略や並び替えは抑制できるけど
CPUが実行時に行う最適化には関与しないから無意味
762:デフォルトの名無しさん
11/10/23 21:37:00.66
はあ？
763:デフォルトの名無しさん
11/10/23 21:58:56.17
>>762
少しは勉強しろ
764:デフォルトの名無しさん
11/10/23 22:06:44.84
>>750
atomic_int a = 0, b = 0;
//thread1
a.store_release(1);
int v = a.load_acquire();
int x = b.load_acquire();
//thread2
b.store_release(1);
int w = b.load_acquire();
int y = a.load_acquire();
のときでも x == 0 && y == 0 はありうる?
765:デフォルトの名無しさん
11/10/23 22:06:59.86
意味不明なこと言ってるのがわかってないの？
766:デフォルトの名無しさん
11/10/23 22:07:49.18
>>765
自己レス？
767:デフォルトの名無しさん
11/10/23 22:09:36.03
>>764
//thread1
int v = a.load_acquire();
int x = b.load_acquire();
a.store_release(1);
//thread2
int w = b.load_acquire();
int y = a.load_acquire();
b.store_release(1);
リオーダーされてこうなったら全部0
768:デフォルトの名無しさん
11/10/23 22:11:32.64
>>767
てきとーなこと書くなよ
769:768
11/10/23 22:24:48.00
>>767
すまん勘違いしてた。同じa同士のloadとstoreはひっくり返るはずが無いと思ったが実際の動作ならそうなりえるよね。
770:デフォルトの名無しさん
11/10/23 23:05:40.90
>>760
それvolatile無くてもJavaのvolatileと同じ。
volatile変数としてatomicを使えるようになってるだけで、
特別扱いはない。
771:デフォルトの名無しさん
11/10/23 23:19:22.09
>>767,769
同じスレッド上でのリオーダーの話と別のスレッドから見たときの順序の話がごちゃ混ぜになってないか？
a.store_release(1);
int v = a.load_acquire();//a.store_releaseとa.load_acquireは同じオブジェクトなのでリオーダーできない。
int x = b.load_acquire();//その結果b.load_acquireも上に移動できない。
しかしながらseq_cstじゃ無いので他のスレッドから見たときの順序が保障されないので x == 0 && y == 0 はありうる
これでいいんじゃね？
772:デフォルトの名無しさん
11/10/23 23:32:07.62
そのコードで会話が成立してるところが凄いかも
773:デフォルトの名無しさん
11/10/24 00:06:26.80
いまから一生懸命C++11での質問してる人がいるけど、
まともに使えるコンパイラでてんの?
メモリバリアとかよくわかんないなら、
今使えるライブラリを動かして勉強した方が早いんとちゃう?
3年後11に本腰入れたって出遅れはしないだろ。
774:デフォルトの名無しさん
11/10/24 00:09:00.47
３年後には次の規格が出てるよ
775:デフォルトの名無しさん
11/10/24 00:19:19.45
>>738
なみの処理じゃ、IOの影響がでかすぎて、
速度の優劣はIO次第になるな。
例えば、1600個の画像からMD5を採ったとき、
IO状態次第で0.7秒から、1分40秒もの差がでる。
恐らく前者はキャッシュ効果だろう。
スレッドを4本でスレッドプール使って計算したが、
確かに計算は速いものの、結局IOがもたつくとどうしようもなく遅い。
776:デフォルトの名無しさん
11/10/24 00:20:20.50
>>774
03から11の間に規格あったっけ？
777:デフォルトの名無しさん
11/10/25 11:21:35.66
【ＯＳ】 WindowsXP SP3
【言語】 c++
【実行環境】VC++ 2010 + boost
【その他特記する事項】-
以下に示す2パターンの記述で、どっちでもイイヨ…、どちらが良い、どちらもダメで他の方法が良いか、ご指導お願いします。
マルチスレッド処理するクラス(以下、クラスA)をつくっています。
以下のスレッドを生成します。
・ネットワーク経由でデータを受信する
・受信したデータを内部で加工する
・加工したデータを画面に表示する
スレッドを実行する方法について考えています。
{
クラスAのインスタンスaを作成
aとスレッド関数名を指定してスレッド生成・開始×3
join
}
とするか
{
クラスAのインスタンスを生成して
コンストラクタ内でスレッドを生成・開始
}// デストラクタ内でjoin
とするか迷っています。
普通は前者のようにする気がします。
後者にすると、一見スレッドが生成されていることに気がつきません。
ですが、クラス・インスタンスの独立性的なもので考えると後者でも良いような気がしました。
が、結局、デストラクタでjoinすることで、
元のスレッドが、a配下のスレッドの終了を待機してしまう、という訳のわからなさがあります。
以上、よろしくお願いします。
778:デフォルトの名無しさん
11/10/25 11:37:57.33
どうでもいいよ
どっちみちそんな手軽にあちこちで無意識に使うもんじゃないでしょ
779:デフォルトの名無しさん
11/10/25 11:46:17.15
デストラクタでJoin失敗したらどうすんの
780:デフォルトの名無しさん
11/10/25 12:39:33.84
スレッドがどうとかより機能別に関数を作れ
781:777
11/10/25 12:55:15.17
レスどうもです。
＞どうでもいいよ
作法とかあったらしりたいなぁ、と思いました。(マルチスレッド自体はじめてで。)
今回は簡単なツールなので確かにどうでもいいのですが…。
＞Join失敗したらどうすんの
失敗するのですか？
戻り値がvoidだったので気にしてませんでした。
例外が投げられるのかな。調べてみます。
782:777
11/10/25 13:10:39.43
あれ？
結局デストラクタでJoin失敗した場合と、デストラクタじゃない方でJoin失敗した場合とで、どういう違いが起きるのです？
＞スレッドがどうとかより機能別に関数を作れ
一つのクラスに押し込めるな、ということでしょうか？
関数は各スレッドで(クラス内で)独立したものを使っていて、
関数間のデータの受け渡しもクラス内のメンバ変数を使っているので、
クラスの使い方的に、理にかなっているかなぁなんて考えたのですが…。
783:デフォルトの名無しさん
11/10/25 14:00:13.83
構造体や変数に volatile とつけたときの
本当の意味を知る方法
784:777
11/10/25 14:47:21.75
レスどうもです。
＞構造体や変数に volatile とつけたときの
volatileとか初めて知りました。何てこと…。
でも、コンパイルのコード生成的なオプションで、マルチスレッド指定していれば、変な最適化はされなくないですか？
＞どちらもダメで他の方法が良いか
に対するレスですよね？
781か782でしょうか？
785:デフォルトの名無しさん
11/10/25 15:09:03.14
>>777
受信スレッドと加工スレッドと表示スレッドに分けるんだろ。
で、スレッド起動したら基本は動きっぱなしだと理解したんだが。
それなら、受信クラスと加工クラスと表示クラスに分けて、
スレッド起動(受信クラス、ネットワーク情報、受信バッファ)
スレッド起動(加工クラス、受信バッファ、表示キュー)
スレッド起動(表示クラス、表示キュー、表示デバイス情報)
こんな感じで起動すればいいんじゃないのかね。
こういう作りにしておけば、例えばメインスレッドで表示をするように変更するのも簡単だ。
786:デフォルトの名無しさん
11/10/25 15:51:18.15
TBB使えば
787:777
11/10/25 17:02:22.59
＞受信スレッドと加工スレッドと表示スレッドに分けるんだろ。
＞で、スレッド起動したら基本は動きっぱなしだと理解したんだが。
はい。
＞こんな感じで起動すればいいんじゃないのかね。
了解です。
変にまとめすぎない方がいい感じなんですね。
「独立して動くスレッド達のだから、メインでは、何もしないのがいいのかなぁとか無駄に凝ってました。
＞TBB使えば
それは、どのような意図でです？
boostとそっくりな気がして、どの様にとりあつかえばヨイのか見当がつかないです。
788:777
11/10/25 17:13:53.40
detach()というメソッドが何を目的にしているのかいまいち理解できないので教えて欲しいです。
>>785 を利用させてもらうと、boost::threadを使う場合(thread_groupで無い場合)
boost::thread スレッド起動1(受信スレッド関数名、受信クラス、ネットワーク情報、受信バッファ)
boost::thread スレッド起動2(加工スレッド関数名、加工クラス、受信バッファ、表示キュー)
boost::thread スレッド起動3(表示スレッド関数名、表示クラス、表示キュー、表示デバイス情報)
で、スレッドを起動しますが、
「あとは、エラー出ても、例外投げても、私は知らないから勝手にやってね。」という場合は、
スレッド起動1.detach(); スレッド起動2.detach(); スレッド起動3.detach();
と書いてしまっていいんですか？
join()しないと、メモリ的に何かおかしいことになりそうな気がして、ドキュメントを探しているのですが、捗っていないです。
デタッチ自体初めて知った概念なので、理解がすすまないです。
デタッチ：デバッガなどが監視・制御の対象としていた(アタッチしていた)実行中のプログラム(プロセス)を監視下から外すことを「デタッチする」という。
というのは、わかったのですが、自動変数である「スレッド起動x」は、メイン終了で開放されるのではないのですか？
789:デフォルトの名無しさん
11/10/26 12:59:59.34
>>788
pthread_detachとCloseHandleをスレッドに対して
実行した場合を調べてみ。
790:デフォルトの名無しさん
11/11/03 18:34:53.11
visual c++ 2010 Express
についてくる、
Concurrency::concurrent_queue
を使って、
要素にstringを含んだ構造体(そういえばstringだけって試してないな)を取り扱うと、
デストラクタで開放するときに、アクセス違反が起きるんですけどどうすればいいですか？
という質問をしたいのですけど、Visual C++を教えるスレッドへ行ったほうがいいです？
とりあえず、英語圏で同じ問題を出している人をみつけたんですけど、みたいな状態で、アロケータ？なんだそりゃ？な状態なのです。とりあえず英語読んできます。
ageて申し訳ない。
791:790
11/11/03 18:39:17.13
申し訳ないです。
よく考えたら、Concurrency::concurrent_queueとマルチスレッドって関係浅いですね。
他で訊きなおします。
失礼しました。
792:デフォルトの名無しさん
11/11/03 20:00:51.82
そういえばppl.hのメモリリークのバグっていつの間にかなおってたな
793:デフォルトの名無しさん
11/11/15 10:54:58.38
p://ideone.com/CZz2M
Concurrency::parallel_forを使っているかたはいらっしゃらないでしょうか。
画像処理のシミュレータをVC2008Expで書いていて
CreateThreadによる手書きマルチスレッドからOpenMPと移行し
速度的に変わっていないことを確認したのですが
VC2010Expに移行し、OpenMPの導入方法がわからなかったので
parallel_forに書き換えてみた所、異常に遅いのです。
プロジェクトの設定は、2008はリリースデフォルト+OpenMPサポート
2010はリリースデフォルトです。
何か設定を間違っているのかと思うのですが、どなたかわかりませんか?
【ＯＳ】XP sp3 32bit
【言語】VC++ 2008/2010 Express
【実行環境】 Core 2 Extreme X9650 3.45Ghzくらい
794:デフォルトの名無しさん
11/11/15 11:43:33.72
プログラミング初心者で課題が出たんですけど…
教えて頂けるとありがたいですm(__)m
･九九の表をVisual Basicで完成させる
･1から100までの整数の和を求める
お願いします
795:デフォルトの名無しさん
11/11/15 13:40:05.39
>>794
スレ違い。
BASICの宿題はお前にまかせた
ｽﾚﾘﾝｸ(tech板)
796:デフォルトの名無しさん
11/11/15 18:00:31.85
マルチスレッドで九九表を作るという課題かもしれない
797:デフォルトの名無しさん
11/11/15 18:18:03.92
処理そのもののコストよりもスレッド作るコストの方がでがいわｗ
798:デフォルトの名無しさん
11/11/15 19:26:55.17
>>797
つまり、よりコストを下げるためにFiberを実装する宿題と言うことか。
799:デフォルトの名無しさん
11/11/16 00:04:15.44
教官が採点不能すぐるｗｗｗ
800:デフォルトの名無しさん
11/11/16 00:07:19.51
SSE使おうぜ
801:デフォルトの名無しさん
11/11/16 08:01:57.58
SSEを使ったからといって、マルチスレッドとはいえないがな。
802:デフォルトの名無しさん
11/11/16 09:10:50.87
数値計算ならSSEとマルチスレッドを両方使うのが常識だな
803:デフォルトの名無しさん
11/11/16 13:08:03.64
ならGPGPUで
804:デフォルトの名無しさん
11/11/16 17:08:36.01
SSE+マルチスレッドなら九九ならず9999999×9999999くらいの表を作るべきだな
805:デフォルトの名無しさん
11/11/16 17:35:23.60
約100T個
806:デフォルトの名無しさん
11/11/16 20:09:53.33
GPGPUってマルチスレッドなのか?
一応処理単位をスレッドと呼ぶけどそれじゃSSEもマルチスレッドになるような
数値計算だとデータ並列が基本だから数値計算プログラムを書く人から見たら
いわゆるマルチスレッドと大して違わないんだろうが
807:デフォルトの名無しさん
11/11/16 20:32:03.35
GPGPUもSSEも「並列化プログラミング」だよね
ただそれらはスレッド無しでも使える技術だから、このスレでは微妙かも
以前は並列処理スレがあったけど、そちらはdat落ちした
808:デフォルトの名無しさん
11/11/16 22:50:07.24
SSEはSIMDだろ、んでGPGPUとスレッドはMIMD。
SSEとGPGPUは機能としては勿論、分類としても全然違うと思うぞ。
809:デフォルトの名無しさん
11/11/17 02:40:46.84
GPGPUで重要な性質はSIMDだろ
いかにSIMDを生かせるかで性能が決まって、アルゴリズムもそれが前提になる
810:デフォルトの名無しさん
11/11/17 02:59:04.56
GPGPUの各クラスタというか構成単位について見ると
同時に異なる命令を実行していることがあり得るので
Single Instructionではない
フリンの分類に当てはめるならMIMD
しかし、もっと狭めたSPMDっていう表現のほうが適切じゃないの
811:デフォルトの名無しさん
11/11/17 03:21:03.30
複数の別々の画像に対して同じ処理を並列に独立に実行したら
タスク並列かデータ並列かどっちになるの?
812:デフォルトの名無しさん
11/11/17 07:24:31.73
どっちも使ってるで良いだろ
813:デフォルトの名無しさん
11/11/20 20:50:45.10
GPUは投機実行するか、単に並列実行するかで方向性がかなり変わるよね。
もっとも、GPGPUとしては投機実行の方が需要が多いだろうけど。
投機実行となると実行してる命令はクラスタ毎に異なるから
やっぱMIMDとしての使用がメインという事でないか。
814:デフォルトの名無しさん
11/11/20 23:03:59.97
GPGPUは「ゆかいな牧場」のメロディーで発音したくなる。
815:デフォルトの名無しさん
11/11/21 00:44:45.34
>>814
しまった、そう発音していた。
816:デフォルトの名無しさん
11/11/21 18:45:55.58
>>815
おまえがいちろうか、
817:デフォルトの名無しさん
11/11/21 19:42:22.04
大人になってから改めて歌詞を見ると下ネタにしか見えないな
818:デフォルトの名無しさん
11/11/22 19:52:25.40
シングルスレッ～ドでコード おまえ書いてたころ～
819:デフォルトの名無しさん
11/11/22 20:32:28.94
人というのは知っている言葉を敏感に聞きとれるようになっている
すなわち、それは>>817がエロくなっただけのこと
820:デフォルトの名無しさん
11/11/24 06:40:15.25
かゆいな牧場
821:デフォルトの名無しさん
11/11/25 22:40:29.78
atomic_store、stomic_load関数って自分で実装しなくてはならない羽目になったらどうするんですか
WindowsAPIを探してみたんですがよくわかりません
Interlockedシリーズを応用するんでしょうか？
822:デフォルトの名無しさん
11/12/13 03:13:09.01
メモリ競合は、あるスレッドがあるアドレス位置に書き込みを行っている最中に、
別のスレッドがそのアドレス位置に書き込み、もしくは読み込みを行うことで、
そのアドレス位置に中途半端にデータが書き込まれた状態で別のデータが書き込まれる、
あるいは読み込まれることによって起こる、という認識で正しいでしょうか？
その場合、それはビット単位で起こるのでしょうか？
たとえば以下のように、ある変数に2スレッドで書き込み、1スレッド読み込む場合、
変数の値が 0x00, 0xff 以外の値になることはあるでしょうか？
もし変数のサイズがもっと大きければどうでしょう？
// thread0
var = 0x00;
// thread1
var = 0xff;
// thread2
if( var ) ; // ...
823:デフォルトの名無しさん
11/12/13 05:03:20.45
>>822
環境次第。その対象アドレスにあるのが普通のメモリなら、ビット単位と言う事は無いのでその2値以外になることはおそらくない。
824:デフォルトの名無しさん
11/12/13 17:01:56.05
>>822
どのサイズが問題なく読み書きできるかは環境(CPUやVM等)しだい
(intはOKだがdoubleはだめといった感じ)
825:デフォルトの名無しさん
11/12/13 17:32:59.62
>>822
32ビットx86なら4バイトアライメントされたアドレスの4バイトをmovでアトミックに書き込める、
これが8バイトだとmov2回になるので（もっと違う値なら）2値のどちらでもない状態が存在する、とかいうのはある
でも付いて行けなくなるから考えないほうがいいぞ
826:デフォルトの名無しさん
11/12/14 04:35:01.63
>>823-825
ありがとうございます。
とりあえず、メモリを読み書きする電気的な信号などがバッティングして
データが飛んだりハードが壊れたりということはないんですね。
827:デフォルトの名無しさん
11/12/14 06:38:46.37
メモリ競合程度でハード自体が壊れるなら欠陥品と言わざるを得ない
828:デフォルトの名無しさん
11/12/14 08:09:32.50
>>826
その環境が組み込みでメモリマップドI/Oの先にいい加減な回路が繋がっていたりしたら、壊れるかも知れんが。
尤も、そんな回路ならマルチスレッドに関係なく壊しそうだけど。
829:デフォルトの名無しさん
11/12/14 15:52:37.83
そんなハードウェア上で何も組める気がしないぜ
830:デフォルトの名無しさん
11/12/14 16:07:15.72
>>829
しかしそれでも組むのが我々の仕事だ
831:デフォルトの名無しさん
12/01/15 18:00:02.48
物理ディスクとのI/Oコストってデカイじゃん
もしかしたらアーカイブのままメモリに読み込んで、
メモリ中でアーカイブ展開しながら処理した方が
早いんじゃないかとも思うんだが、
検証しやすいサンプルとか無い？
高速展開と、部分抽出が出来れば効果が現れやすいと思う。
832:デフォルトの名無しさん
12/01/15 18:23:45.87
>>831
20年くらい前に、そういうコンセプトのフリーウェアがあったっけな。
とりあえず試してみたら良いだろ。
圧縮率を20%と仮定するなら、100KBのreadにかかる時間と、
80KBのreadにかかる時間差を計測する。
後はオンメモリに置いといて、その時間差ないに解凍できるかだ。
ちなみにディスクの待ち時間の大部分はヘッドのシーク。
データサイズが多少小さくなったところで、得られる時間は少ない。
データが連続している場合、20KB減ったところで1msも短くならないぞ。
833:デフォルトの名無しさん
12/01/15 20:58:51.56
何だ無駄か。読み込みスレッドで随時解凍しながら取り込めば、
ワーカーの処理待ちを減らせるかと思ったのに。
834:デフォルトの名無しさん
12/01/15 22:18:40.46
いや、IO自体のオーバーヘッドは今でもバカにならない。
ネットワーク上のファイルIOもレイテンシがでかい。
いまどき数百MBからGBオーバーのファイルも少なくないんだから、本気でバッファを大きくとるか、コンカレントに処理して欲しい。
アーカイバをいくつか使い比べると何割というレベルの速度差がある。
速い奴はちゃんとそういう所にも気を配ってる。
835:デフォルトの名無しさん
12/01/15 23:21:05.40
そういえば昔、NetWareというサーバOSがあったな
クライアントのローカルＨＤＤをアクセスするよりも
LANでつながったNetWareサーバ上のファイルをアクセスする方が高速だった
古きよき時代
836:デフォルトの名無しさん
12/01/16 01:37:22.73
JavaのFutureとpthread_joinとの違いが、
スレッドプール使えるかどうかぐらいしか解からん。
アレは、pthread_joinとスレッドプール以外じゃ何が違うの？
(オブジェクトと例外返すのは置いといて)
837:デフォルトの名無しさん
12/01/16 01:47:25.07
いやFutureは結果返すためのものだからそれ置いといたらダメだろ
838:デフォルトの名無しさん
12/01/16 02:01:11.36
pthread_joinも結果は返せるからね。
pthread_joinを軽くラップするだけで、
例外を返すのもオブジェクトを返すのも簡単にできちゃう。
結果を返す事だけに注目すると差異としてはあまりに小さいと思うけど。
839:デフォルトの名無しさん
12/01/16 11:48:41.44
>>831
読みきってから処理するのではなく
読みながら処理する
840:デフォルトの名無しさん
12/01/16 13:00:46.78
無圧縮データでディスクIOが、どれくらい
コスト掛かるのか調べてみた。
調べ方は2つスレッドを走らせ、
片方はひたすらカウント、
もう片方はファイル読み込みしながら、
読み込んだバイト数分だけカウント。
どちらもカウント変数をクリティカルセクションで囲んだ。
CPUは2コア。
この条件で実行するとファイル読み込み
してるほうが1/8程度遅かった
遅い遅い言うけどそうでも無いのな。
841:デフォルトの名無しさん
12/01/17 17:41:36.51
キャッシュ読んでるだけじゃないのそれ
842:デフォルトの名無しさん
12/01/17 20:46:09.02
まぁ、NTFSの圧縮ファイルシステム使って早くなるなら、
みんな圧縮してるよね。
843:デフォルトの名無しさん
12/01/18 00:09:55.35
それは一旦全部解答してから読み込むからでしょ
844:デフォルトの名無しさん
12/01/18 15:32:20.55
その認識は完全に間違ってる
URLﾘﾝｸ(blogs.msdn.com)
845:デフォルトの名無しさん
12/01/21 07:08:56.51
2chのログは圧縮フォルダに入れた方が圧倒的に速い
846:デフォルトの名無しさん
12/01/22 10:58:15.73
パソコン側のHDDキャッシュがお馬鹿ってことじゃあ
847:デフォルトの名無しさん
12/01/23 09:41:58.18
>>846
正しいだろ。
848:デフォルトの名無しさん
12/02/21 23:37:31.35
ディスク絡みのスレッドの話だけど、HDDのランダムアクセスの遅さに驚愕した。
任意のスレッド数(プール使用)で、複数同時にファイルを読み込み、
MD5ハッシュを取り出してファイル比較するツールを作った。
んで、1ファイル1MB未満のファイル群と、1ファイル40MBを超える
ファイル群に対して実行してみた。4コア環境で実行したら
1MB未満だと3スレッドが最速。40MB以上だと1スレッドが最速ってな結果になった。
40MB以上で、1スレッドだとディスクアクセスが100MB/sを超える。
40MB以上で、4スレッドだとディスクアクセスは30MB/s未満まで低下した。
みんなは、この辺どう回避してんの？
849:デフォルトの名無しさん
12/02/21 23:46:23.99
>>848
非同期ＩＯとか、メモリマップドファイルとか。
複数スレッドから同時アクセスなんかしたら、ディスクシークが増えて、
帰って遅くなるのは当たり前。
850:デフォルトの名無しさん
12/02/21 23:47:16.21
>>848
NCQにまかせて神に祈る
ってのは冗談で
1. 読む順番が決まっているならデータをデフラグでその順番に並べておく
2. その順番に読めるように1スレッドで読みに行く
851:デフォルトの名無しさん
12/02/22 00:02:11.03
>>849
理屈じゃ分かっちゃいたんだけどねぇ。まさかここまで遅いとは・・・。
>>850
並列化は諦めるしかないのかねぇ。
852:デフォルトの名無しさん
12/02/22 00:31:00.86
ファイルを読むスレッド(1つだけ)とMD5の計算他をするスレッドを分けるとか？
CPU時間がどっちかに偏ってたらだめかもしれませんが。
853:852
12/02/22 00:34:57.35
って850さんが既に言ってますね。ファイルを読むスレッド1＋それ以外の計算をするスレッド複数。
そしてディスクアクセスの時間＞＞計算の時間なら、ディスクが物理的に1つしかない以上は並列化は無理かと。
854:デフォルトの名無しさん
12/02/22 00:49:03.05
>>852
それが微妙なんだよね。
MD5の計算って一般的に順序依存があるから、
1つ前に計算した計算結果が無いと、
次の計算が始められないんだよ。
そんなんもんで、ファイル別なら順序依存が無いから
とりあえず、1スレッド1ファイル処理にしてたんだけど。
実は、ディスクアクセスというよりMD5の
順序依存が一番足引っ張ってんのかもね。
あと、MD5の計算時間だけど読み込みの10倍遅いよ。
855:デフォルトの名無しさん
12/02/22 00:57:48.08
>>854
～かもね、とかの妄想に付き合うのは疲れるから、調べてから書けよ
856:デフォルトの名無しさん
12/02/22 01:17:35.11
>>855
調べるつってもなぁ。発想の問題じゃない？
これ以上調べられることあるかい？
857:デフォルトの名無しさん
12/02/22 01:18:33.05
頼むから喧嘩はやめてくれよな
858:デフォルトの名無しさん
12/02/22 01:18:41.54
> 順序依存が一番足引っ張ってんのかもね。
を明らかにすればいいじゃない
859:デフォルトの名無しさん
12/02/22 01:24:03.16
＞あと、MD5の計算時間だけど読み込みの10倍遅いよ。
あれ？それならいけるんじゃない？
仮に11コアのCPUがあったとして、
1コア目→ディスクから10個のファイルを読み出してメモリに吐く
2～11コア目→1コア1ファイル分担当で計算
って形で10コアまでスケールするはずだと思うんだけど。コアはスレッドと読み替えてもok。
860:デフォルトの名無しさん
12/02/22 01:33:14.66
>>859
ロード時間L, MD5計算時間Mとすると(L=10M)
馬鹿正直にやったら10(L+M) = 110M
お前のやり方だと10L+M = 101M
どこがスケールしてるんだ？
ついでに2スレッドでも101Mは出ると思う
861:デフォルトの名無しさん
12/02/22 01:34:10.53
>>860
ごめんどっちが遅いのか勘違いした
吊ってくるわ
862:デフォルトの名無しさん
12/02/22 01:39:04.31
>>854
計算が10倍遅いなら、シングルリーダスレッドでも十分にペイする。
ただ、机上で計算すればあんたの実測値なら3並列と4並列に分かれ目がある。
ファイル一件の読み込みを1、比較するってことなんでサイズは全ファイル
ほぼそろってるとして、4対象の場合のそれぞれの最長パスは
1リーダ+4計算スレッド： 4+10 = 14
全部で1スレッド： 1*4+10*4 = 44
4(リーダ+計算)スレッド：1*(100/30)+10 = 13.33 (100MB/sが4スレで30MB/sになったから)
まあ実測すると他のプロセスとかとの兼ね合いでまた変わるだろうけど、
多分安定度で言えばシングルリーダスレッド＋N計算スレッドじゃないかなあ。
OSのページキャッシュに乗っている事が期待できる状況ならまた別だけど。
863:デフォルトの名無しさん
12/02/22 01:42:35.74
>>858
ディスクアクセスの改善が無理ならMD5の
順序依存を直すしか無いと言えるんだけど。
もう本当に打つ手がないか意見が聞けないとなんとも。
>>859
確かにね。最終的にはそれが一番効率がいいのかなとも
思うんだけど、ただその方法は計算するファイルは1ファイルまるごと
読み込まないといけないんだよね。
そこがちょっともっといい方法が無いかと引っかかるよ。
864:859
12/02/22 01:45:16.15
861が俺のレスみたいに見えるので一応自己弁護しておこうｗ
ロード時間L, MD5計算時間Mとすると10L=M
シングルスレッド→10(L+M)=110L
11コアによるマルチスレッド→10L+M=10.1L
とほぼ11倍の性能ということで理屈上スケールはするはずだ、と。もう寝るおやすみ～