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

1 ：デフォルトの名無しさん：2012/06/15(金) 01:31:57.88 .net

マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室 その8
http://toro.2ch.net/test/read.cgi/tech/1253521167/

■過去スレ
その１ 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/
その７ ttp://pc12.2ch.net/test/read.cgi/tech/1215253576/

OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他特記する事項】

2 ：デフォルトの名無しさん：2012/06/15(金) 01:35:25.58 .net

■関連スレ・関連性の高いスレ

ネットワークプログラミング相談室 Port28
http://toro.2ch.net/test/read.cgi/tech/1334736934/

3 ：デフォルトの名無しさん：2012/06/15(金) 03:59:42.18 .net

>>1 乙

前スレ >>994
並列実行「可能」でも「スケールする」かは知らんぞ。

OpenMP なら !$omp parallel do としてコンパイルオプション /Qopenmp

4 ：デフォルトの名無しさん：2012/06/15(金) 16:15:07.07 .net

>>前すれ995
そういうオプションがあるのですね，レポートと書き直したソースを添付します．

http://www5.puny.jp/uploader/download/1339744079.zip
pass:giko

potential OUTPUT 依存関係
らしいですが，ググってもよくわかりません．依存関係がないように>>前すれ999のようにpureに書き換えたのですが．

>>前すれ997
これは試しにつけてみただけのものです，やはり使い方が違いますか・・．

5 ：デフォルトの名無しさん：2012/06/15(金) 18:14:50.61 .net

gfortran -O3 20120528_fast_pararell_subroutine.f90 -ftree-vectorize -msse2 -ftree-vectorizer-verbose=2

6 ：デフォルトの名無しさん：2012/06/15(金) 18:54:01.14 .net

彼女二人と同時にデートする時はマルチスレッドじゃないといけないんだけど
どうすればいいかな

7 ：デフォルトの名無しさん：2012/06/15(金) 19:08:46.12 .net

時分割でがんばれ

8 ：デフォルトの名無しさん：2012/06/15(金) 21:41:34.19 .net

Analyzing loop at 20120528_fast_pararell_subroutine.f90:237
237: not vectorized: not suitable for gather D.2660_224 = *shoi_69[D.2659_223];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:196
196: not vectorized: not suitable for gather D.2600_148 = *a_147(D)[D.2599_146];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:150
150: not vectorized: loop contains function calls or data references that cannot be analyzed
Analyzing loop at 20120528_fast_pararell_subroutine.f90:131
131: not vectorized: not suitable for gather D.2767_169 = *a_86(D)[D.2766_168];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:91
91: not vectorized: not suitable for gather D.2704_87 = *a_86(D)[D.2703_85];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:37
37: not vectorized: not suitable for gather D__I_lsm.780_635 = MEM[(real(kind=8)[0:] *)D.2433_241][pretmp.758_17];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:38
38: not vectorized: not suitable for gather D.2485_318 = MEM[(real(kind=8)[0:] *)D.2298_95][D.2484_317];

9 ：デフォルトの名無しさん：2012/06/16(土) 12:26:31.55 .net

>>4
ループ間で出力変数に依存関係があるかも、という判断。

○ i, j は value 属性を付け、b は戻り値にする。
○ サブルーチン inv の宣言部に interface で sho_det の引数属性を書く。

ここまでで依存はクリア、反復回数が少ないかも、というようになる。
/Qpar-threshold0 オプション (100〜0) で並列化は完了。

10 ：デフォルトの名無しさん：2012/06/16(土) 12:48:12.18 .net

bに依存がないことくらい解析できてもよさそうなのにね

11 ：デフォルトの名無しさん：2012/06/16(土) 16:27:05.54 .net

sho_det呼び出しの２重ループで並列化できるの？

12 ：デフォルトの名無しさん：2012/06/16(土) 16:52:50.21 .net

双子と付き合う時はマルチスレッドのチンポ子が欲しい。

13 ：デフォルトの名無しさん：2012/06/16(土) 16:54:32.86 .net

クリティカルセクションとかミューテクスって重いんですか？
秒間2500回とかマジキチですか？

14 ：デフォルトの名無しさん：2012/06/16(土) 17:00:15.54 .net

400μ秒は今のパソコン環境でも、厳しいんじゃね
何をしたいかにもよるけど、専用環境作ったほうがハマらんかもね

15 ：デフォルトの名無しさん：2012/06/16(土) 17:19:32.25 .net

ロックフリー！

16 ：デフォルトの名無しさん：2012/06/16(土) 17:33:56.57 .net

>>13
そのあたりだと、API 呼び出しのオーバーヘッドもバカにならないから
自前で実装したほうがいいんじゃね？

17 ：デフォルトの名無しさん：2012/06/16(土) 21:17:30.95 .net

https://gist.github.com/2841832
によれば
> Mutex lock/unlock 25 ns

18 ：デフォルトの名無しさん：2012/06/16(土) 22:25:28.46 .net

>>13
重いけどそれくらいならいけると思う
できるならスレッドごとにリソースもって
最後に合体させたほうが速い

19 ：4：2012/06/16(土) 23:07:53.93 .net

申し訳ありません，並列化ですが，解決しました．
/Qpar-threshold(並列化のしきい値)の値を100から20ぐらいまで下げたら5スレッドで実行されました．

ただ，ものすごく，計算が遅くなってしまって，なおかつ不必要なところまで並列化されてしまったようです．
このループだけ並列化したいっていうような指定ってできるのでしょうか？

20 ：デフォルトの名無しさん：2012/06/16(土) 23:18:15.13 .net

>>17
Mutexってスレッド数によると思うんだけどな。
シングルコアならオンキャッシュで対応できるけど、
マルチコアだったりマルチCPUだったらメモリ参照と大差ないと思う。

21 ：デフォルトの名無しさん：2012/06/17(日) 02:24:44.41 .net

答え教えてもらって、闇雲にやるのが今風なの？

22 ：デフォルトの名無しさん：2012/06/17(日) 02:28:46.34 .net

それって、単純ループがスレッド化されただけじゃねえの？

23 ：デフォルトの名無しさん：2012/06/17(日) 03:56:01.16 .net

実行環境に寄って自動で最適化して欲しいよね。
ちょっと違うけどjitみたいに自分でプロファイルとって実行処理罹る所を重点的に最適化とかさ。

4coreの環境と64coreの環境といちいち最適化するのめんどくさい。

24 ：デフォルトの名無しさん：2012/06/17(日) 04:08:44.71 .net

core数増えたから、早くなるってわけでもないでしょうに

25 ：デフォルトの名無しさん：2012/06/17(日) 06:28:14.10 .net

効率が悪かろうと並列化したいループには !DEC$ PARALLEL ALWAYS
※ 依存性に目をつぶれという指示ではない

> 64core の対応
３日かかる計算を１時間に押し込みたいなら、やる価値はある。
１分の処理が１秒になることを期待するなら、最適化する時間のほうが長い。

そもそも、大体の 64core での性能問題は 4core では小さくて見えないだけ。
スケールするとかしないとかはそういう話。

26 ：デフォルトの名無しさん：2012/06/17(日) 14:48:00.38 .net

速くなってくれないと高額な多コア買った意味無いんだが。

27 ：デフォルトの名無しさん：2012/06/17(日) 19:02:58.50 .net

それは、プログラム作ったベンダーに言え。
場合によっては、どれくらい高速化するかの見積もりくらい出してくれるだろ。

28 ：デフォルトの名無しさん：2012/06/17(日) 20:27:37.75 .net

分散処理できるように考えるほうが難しいのに
道具によってはできることとできないことがあるでしょ

29 ：デフォルトの名無しさん：2012/07/06(金) 19:30:56.61 .net

多コア化すれば、将来は、割込優先スレッド用コア、時分割スレッド用コア、OS用コアに別れて、それぞれのコアが空き時間でどうでもしてくれスレッドを処理するようになる気がする。
そうしないとスケジューリングに費やすコストが無駄だ。

30 ：デフォルトの名無しさん：2012/07/06(金) 19:38:42.21 .net

あまり賢そうに見えないな

31 ：デフォルトの名無しさん：2012/07/06(金) 19:45:56.15 .net

gpuが標準的になった時点で、非対称プログラミングが当たり前になるから、コア間に使い分け、役割分担が発生するのは必然じゃないかな。もっともどのコアがどの役割をやるかは、スケジューラが決めることになるけど。

32 ：デフォルトの名無しさん：2012/07/06(金) 19:58:44.83 .net

標準的な入出力は動くコア決めたほうがいいかもしれんけど
プロセス、スレッドはどのコアで動こうが関係無いような
どうせ、暇な？コアに割り当てられるだろうから

33 ：デフォルトの名無しさん：2012/07/06(金) 20:28:22.95 .net

linuxだとこういう指定が出来るようだ
ttp://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/sched_setaffinity.2.html

34 ：デフォルトの名無しさん：2012/07/06(金) 22:01:45.18 .net

それぐらいは WindowsNT 4.0 からあるが。

SetProcessAffinityMask
http://msdn.microsoft.com/ja-jp/library/cc429334.aspx

35 ：デフォルトの名無しさん：2012/07/06(金) 22:04:26.89 .net

コア数とかうるさい割にapiのことは言わんのね？

36 ：デフォルトの名無しさん：2012/07/21(土) 14:53:22.69 .net

pスレッドについて教えてください。


関係性のない処理を行う２つのスレッドＡ、Ｂを同時に動かし始めたいのですが、

・スレッドＡの待ち状態にpthread_cond_wait(&cond, &mutex1);

・スレッドＢの待ち状態にpthread_cond_wait(&cond, &mutex2);

として（condは同じで、mutexが異なる）、これらを動かし始めるために別スレッドで

pthread_cond_broadcast(&cond);

をコールしたのですが、思ったとおりに動いてくれません。
なにがいけないのでしょう？
（pthread_cond_wait()の使い方を間違えている？）

37 ：デフォルトの名無しさん：2012/07/21(土) 14:57:02.99 .net

馬鹿には無理

38 ：デフォルトの名無しさん：2012/07/21(土) 15:18:21.14 .net

>>36
broadcast を受ける側のスレッドは、 broadcast するときに wait していなければいけない
broadcast したときに wait しているスレッドがいなければ、無駄撃ちになる
通常 cond が mutex と一緒に使われるのは、ターゲットが wait に入る一瞬前に broadcast を撃って運悪く外れたりするような事態を回避し、確実に当たるようにするため
思ったとおりに動いてくれないというのなら、あなたの使い方には何か誤りがあって、そういった問題を防ぎ切れていないのだろう

39 ：デフォルトの名無しさん：2012/07/21(土) 15:33:58.32 .net

>>38
素朴に待っていると思っていたスレッドが、実は待っていないせいで
シグナルがすり抜けていたということですね

このての、「関数を素朴に並べただけでは思いどおりに動作しない」問題の対応方法には
それぞれに決まった「お作法」「イディオム」がありそうな気がしますが、どうなんでしょう？


ともかく、ありがとうございました

40 ：デフォルトの名無しさん：2012/07/21(土) 15:42:20.05 .net

>>39
pthreadの粒度が小さい場合、threadの実行順序がぐだぐだになるから要注意。
結論としては、充分長い処理でもない限りcond_waitは使えない。

41 ：デフォルトの名無しさん：2012/07/21(土) 15:49:59.71 .net

>>40
頭で考えたアルゴリズムを実験するときに「安全装置」を省略したせいで
かんたんなこーどなのにはまるなんてありそうですね・・・・

自分が使いたい本番コードは、各スレッドの処理に十分なマスがあるので
素朴なつくりでもそれなりに動いたかもしれませんが、
再現性のないトラブルが発生する前にそういう問題を認識できてよかったです

ありがとうございました

42 ：デフォルトの名無しさん：2012/07/21(土) 16:06:39.87 .net

>>41
去年の暮れ辺りに悩んでいたのが、mutexでスレッドプールを管理していたツールなんだよね。
mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
自分が待たずにロックしちゃうことに。
メインスレッドでmutex_unlock(); mutex_lock()のように書いているのにunlockしたあと
lockするところまで実行できないなんてちょっと想像しにくいぞ。
# 詳細不明だけど、unlockした時点でプールスレッドがスケジュールされてメインスレッドがスケジュールからはずされるっぽい。

43 ：デフォルトの名無しさん：2012/08/25(土) 18:20:47.36 .net

いつでもどんな時にでも
スケジュールから外されても動かされても
大丈夫なように作るのが鉄則

44 ：デフォルトの名無しさん：2012/08/26(日) 08:54:03.71 .net

そうそう。
だから、Web上のサンプルは当てにならない。

45 ：デフォルトの名無しさん：2012/08/26(日) 09:32:08.49 .net

そもそも並列化したいのは高速に処理したいからじゃん？
サンプルにかならずあるsleep()を消すと、途端にまともに動かなくなる
まともに動かなくなるならまだいいけど、「ときどき動作がおかしい」これ最悪

46 ：デフォルトの名無しさん：2012/08/26(日) 09:34:18.81 .net

て言うかサンプルってそういうもんだし。

そもそも >>42 が

> mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
> 自分が待たずにロックしちゃうことに。

って書いてるけど、それ以外にどんな動作を期待してるのか、よくよわからん。

47 ：デフォルトの名無しさん：2012/08/26(日) 09:57:42.57 .net

マトが止まっていないとシグナルがすり抜けちゃうなんて最初はわかんないでしょ

そんなことより、マトがトマるだって・・・・・！喜ｗ

48 ：デフォルトの名無しさん：2012/09/01(土) 15:54:33.37 .net

ﾀﾞﾚﾓｲﾅｲ・・・・・・ﾀﾞｼﾞｬﾚｵｿﾙﾍﾞｼ・・・・・


素朴なＱなんですが、マルチＣＰＵのマシンで、

�@ひとつのプロセスに属するスレッドは、全部同じＣＰＵ（プロセスがいる）で動く

�Aひとつひとつのスレッドが独立してＣＰＵを渡り歩いているように見えるのは、
　スレッド単体ではなく、それの属するプロセスが渡り歩いているため



こういう理解は正しいですか？

49 ：デフォルトの名無しさん：2012/09/01(土) 15:58:04.54 .net

スレッドの割り当てとかはOSが決めてることだからね
OSの挙動に影響しないようなことを考えながらやりませう

マルチCPUじゃなく
単一CPUの時のスレッド等の挙動を考えてみませう

50 ：デフォルトの名無しさん：2012/09/01(土) 16:04:51.98 .net

同じプロセッサ内のコアを移動するならまだしも、別のプロセッサに移動してしまったら、
せっかく溜め込んだキャッシュがおじゃんになってしまうのではないでしょうか？

51 ：デフォルトの名無しさん：2012/09/01(土) 16:11:29.80 .net

逝ってるなマルチコアはCPU毎に命令データキャッシュ持ってるでしょ

52 ：デフォルトの名無しさん：2012/09/01(土) 16:12:43.77 .net

でも分岐したらダメなのでは？

53 ：デフォルトの名無しさん：2012/09/01(土) 16:16:42.15 .net

よく考えたら、分岐するんだったらＣＰＵ移らなくてもダメだった
ﾄﾞﾋﾟｭｯ

54 ：デフォルトの名無しさん：2012/09/01(土) 16:27:35.25 .net

命令の先読みとかやってるの知ってる？

同じ領域を読み込む場合に早くなるってのがキャッシなのでは？

HDDキャッシュとかも同じでしょ

55 ：デフォルトの名無しさん：2012/09/01(土) 16:29:03.73 .net

別のプロセッサに移動してしまったらキャッシュとかおじゃんになってしまうかもしれないが、
ひとつのプロセッサに多数のスレッドが集中して別のプロセッサを遊ばせておくくらいならいくつかのスレッドを移した方がいい場合もある
OSの裁量次第

56 ：デフォルトの名無しさん：2012/09/01(土) 16:32:16.93 .net

キャッシュ知らんでも
スレッド系のプログラム作るのには関係無いような

速度ウンタラは動いてから考えればいい話でしょ

57 ：デフォルトの名無しさん：2012/09/05(水) 01:11:52.99 .net

初心者の質問です

new;した領域 p があって
スレッドAは条件によってdelete p;をする
スレッドBはpを参照する

この時に
変数 blReference, blDeletingを使って

Aの処理中 delete部分
while( blReference ){ Sleep(1); }
blDeleting= true;
delete p;
p = NULL;
blDeleting = false;

Bの処理中 参照部分
while( blDeleting ){ Sleep(1); }
blReference = true;
char* cp = (char*)p:
//以下参照
blReference = false;

っていうのは安全でしょうか？

58 ：デフォルトの名無しさん：2012/09/05(水) 04:17:50.83 .net

>>57
先ず基本的にblReference, blDeletingとも、きちんと扱えるようにしないとダメ。
要は、OSの用意しているクリティカルセクションなどの機構を使う必要がある。
つーか、マルチスレッドプログラミングの基本なんだが、大丈夫なんか?
それと、cpにNULLが代入されること自体は問題ないの?

59 ：デフォルトの名無しさん：2012/09/05(水) 06:16:48.24 .net

weak_ptr使えハゲと言うしかないレベル

60 ：デフォルトの名無しさん：2012/09/05(水) 08:13:29.83 .net

weak_ptrってboost?
マルチスレッドを考慮されていたの?

61 ：デフォルトの名無しさん：2012/09/09(日) 01:13:55.50 .net

>>58
volatileしておけば、
まあいいんじゃない

sleep で待つのは効率はよくなさそうだけど

62 ：デフォルトの名無しさん：2012/09/09(日) 01:44:44.97 .net

volatile使ったとしてもコンパイラによっては安全だとは言えないんだよ

63 ：デフォルトの名無しさん：2012/09/09(日) 01:51:51.18 .net

安全って、思いたい理由の方に興味があるんだけど

64 ：デフォルトの名無しさん：2012/09/09(日) 07:41:49.96 .net

むしろ安全だといえるコンパイラを知りたい

65 ：デフォルトの名無しさん：2012/09/09(日) 14:24:32.10 .net

volatile使っても結果変わらない事の方が多い気がする

66 ：デフォルトの名無しさん：2012/09/09(日) 15:54:34.19 .net

そりゃそうだ

67 ：デフォルトの名無しさん：2012/09/09(日) 16:30:00.96 .net

安全だと思うと、コンピュータがそれを理解して動いてくれると思いたいのかな

68 ：デフォルトの名無しさん：2012/09/12(水) 00:03:54.96 .net

volatileしてダメだったケースに遭遇したことないなあ。

まあboolでの同期・排他は簡単なケースにしか使ってなくて、
まじめなのはcritical sectionとかmutexで排他・同期するから
気がついてないだけかもしれないけど。

69 ：デフォルトの名無しさん：2012/09/12(水) 07:22:51.47 .net

>>57
>// スレッドA
>while( blReference ){ Sleep(1); } // 1
>blDeleting= true; // 3

>// スレッドB
>while( blDeleting ){ Sleep(1); } // 2
>blReference = true; // 4

スレッドの処理が時間的に番号の順で行われる場合がある。
つまり、この処理はスレッド間の排他にはなっていない。
おとなしくクリティカルセクションを使ってロックした方がいい。

70 ：デフォルトの名無しさん：2012/09/22(土) 01:53:58.20 .net

>>69
InterlockedExchangePointerは？

71 ：デフォルトの名無しさん：2012/09/29(土) 20:38:32.52 .net

質問ですが、Windows APIのSetEvent()やWaitForSingleObject()って、
内部で適切にメモリバリアを行うことが保証されていますか？

例えば、下記のケースにおいて、_WriteBarrier()や_ReadBarrier()は冗長？
（メインスレッド側）
　bTerminate = true;　　// volatile bool型
　_WriteBarrier();
　SetEvent(hEvent); // スレッドを起床させる

（ワーカースレッド側）
　WaitForSingleObject(hEvent);　　// 起床されるまで待つ
　_ReadBarrier();
　if (bTerminate) { .... } // メインスレッドから通知されたbTerminateに基づく処理

72 ：デフォルトの名無しさん：2012/09/29(土) 20:49:37.13 .net

も一個、volatile bool a, b; があるとして、
　a = c;
　b = d;
の代入順序は、a, bがたとえatomicな型でvolatileだからといって
プロセッサのアウトオブオーダー実行のレベルでは実施される順序が保たれる保証はない、
よって、上記代入を行ったコア以外のコアからaやbを代入順序依存で参照する場合は
メモリバリアが　必　須　、
という理解で合っていますか

73 ：デフォルトの名無しさん：2012/09/29(土) 21:08:56.80 .net

>>71
http://msdn.microsoft.com/en-us/library/ms686355%28VS.85%29.aspx
> The following synchronization functions use the appropriate barriers to ensure memory ordering:
> ・Functions that enter or leave critical sections
> ・Functions that signal synchronization objects
> ・Wait functions
> ・Interlocked functions

>>72
はい

74 ：デフォルトの名無しさん：2012/09/30(日) 00:03:39.72 .net

>>64
javacやcscじゃね

75 ：デフォルトの名無しさん：2012/09/30(日) 00:12:53.41 .net

メモリバリアってのはgcc特有の表現で
atomicな処理とは関係ないんだけど

76 ：デフォルトの名無しさん：2012/09/30(日) 00:30:58.05 .net

>>73
�dクス
SetEvent()は2番目（・Functions that signal synchronization objects）、
WaitForSingleObject()は3番目（・Wait functions）ってことでおkそうですね

>>75
メモリバリアはアウトオブオーダー実行するアーキテクチャに共通する概念であってGCC固有というわけではないですにょ
とかいろいろあるが説明がﾏﾝﾄﾞｸｾ、

77 ：デフォルトの名無しさん：2012/09/30(日) 00:56:39.75 .net

ただの最適化抑止のおまじないみたいなもんだよ

78 ：デフォルトの名無しさん：2012/09/30(日) 01:05:56.81 .net

>>77
ちょっそれvolatileの方ｗｗｗｗｗ

まあ>73の通り、Windows API内部でよろしくやってくれるので普通はメモリバリアの方は意識しなくて良いっぽい
おそらくUNIXのシステムコールも同様でよろしくやってくれるから知る人ぞ知る知識になってしまうのだろう…

79 ：デフォルトの名無しさん：2012/09/30(日) 01:13:58.15 .net

マルチコア時代の並列プログラミング
〜ロックとメモリオーダリング〜
http://www.nminoru.jp/~nminoru/data/b2con2006_nminoru.pdf

80 ：デフォルトの名無しさん：2012/09/30(日) 01:14:33.03 .net

gccのvolatileってのは、ちょっと特殊なんだよ

81 ：デフォルトの名無しさん：2012/09/30(日) 01:21:19.22 .net

>>77,78
真相はもっと複雑怪奇だったりする
http://yamasa.hatenablog.jp/entries/2009/07/20
http://msdn.microsoft.com/ja-jp/library/bb310595%28VS.85%29.aspx

つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…

82 ：デフォルトの名無しさん：2012/09/30(日) 01:26:29.84 .net

ここらへんの話は
　・（インラインでない）関数呼び出しの副作用を恐れてコンパイラが最適化を自粛
　・volatileによって明示的に最適化が抑制
　・システムコール内でメモリバリアの面倒をみてくれる
　・ハードウェアがコア間でキャッシュのコヒーレンスをとってくれる
といった事情が絡み合った結果、運よく問題を生じないケースも多々あるので
コードをバリバリ書いているような人でもきちんと理解していないことがある（あった）

83 ：デフォルトの名無しさん：2012/09/30(日) 01:27:48.80 .net

アトミック変数とか作って、ド素人に誤解釈されたらどうすんだろ、この人

84 ：デフォルトの名無しさん：2012/09/30(日) 02:22:23.12 .net

>>81
> つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…
そこで面倒を見てくれるのは「release/aquireメモリバリアとしてのみ」であることに注意。
http://yamasa.hatenablog.jp/entry/20090816/1250446250
こっちのSequential consistencyの性質は、VC++2005以降のvolatileでも持っていない。

85 ：デフォルトの名無しさん：2012/09/30(日) 13:33:02.65 .net

>>83
ドシロウトがなんでスレッド使った開発に加わるんだよ

86 ：デフォルトの名無しさん：2012/09/30(日) 13:35:58.01 .net

なんで排他の話ばっか出てくるんだ。
スレッド間で書き換えしまくるような変数なんて殆ど無いだろ。

それはともかく、C++向けのクロスプラとフォームなスレッドキューって無いものか。

87 ：デフォルトの名無しさん：2012/09/30(日) 14:26:20.27 .net

>>86
>なんで排他の話ばっか出てくるんだ。

マルチスレッドで問題になるところと言うか、排他を最近覚えた奴が
使いたくてしょうがないんだろ。

88 ：デフォルトの名無しさん：2012/09/30(日) 15:13:14.28 .net

>>86
スレッドの実装が違うだろう、LinuxとUNIXなら同じだが

89 ：デフォルトの名無しさん：2012/09/30(日) 15:25:27.37 .net

>>85
じゃあ、うわっつらの言葉だけ知ってる甘ちゃん系ではどう？

90 ：デフォルトの名無しさん：2012/09/30(日) 16:54:17.48 .net

>>88
boostとか抽象化レイヤー用意すればできるだろ。

しかし、仕様の安定したスレッドキューがない。
もう、自作スレッドキューを保守するのは嫌だお

91 ：デフォルトの名無しさん：2012/09/30(日) 17:01:09.98 .net

>>90
皮かぶせりゃいいだろうけど、

そこまでして、

そこまでしても

92 ：デフォルトの名無しさん：2012/09/30(日) 21:04:28.14 .net

おまえら何回C++におけるatomicとvolatileの話を繰り返せば気がすむの

93 ：デフォルトの名無しさん：2012/09/30(日) 21:20:03.98 .net

それしかネタがないからさ

94 ：デフォルトの名無しさん：2012/09/30(日) 22:09:45.89 .net

>>92
スレッドキューの話しだせ

95 ：デフォルトの名無しさん：2012/09/30(日) 23:24:16.01 .net

だって手法なんて先駆者が出し尽くしただろ

96 ：デフォルトの名無しさん：2012/09/30(日) 23:53:26.29 .net

スレッドキューって何だ？
スレッドセーフなキューってことか？
それともGCDみたいなタスクキューのことか？

97 ：デフォルトの名無しさん：2012/10/01(月) 00:06:38.53 .net

タスクキューのことだよ。
てかスレッドセーフなキューってなんだよ。それだったら
別にキューに限定せずスレッドセーフなコンテナの話でいいだろ。

98 ：デフォルトの名無しさん：2012/10/01(月) 07:53:47.16 .net

java.util.concurrent.BlockingQueueのことだろ

99 ：デフォルトの名無しさん：2012/10/12(金) 23:18:24.02 .net

同期処理を間違いなく設計するための、何か良い手法やツールはないですかね？

ペーペーのビギナーだというのもあるのですが、
複数のmutexを混在させなければいけない時にぼんやり書いたコードでデッドロックを発生させたり、
waitに到達していないのにシグナル発射する可能性のあるコードを書いてしまって、
そのデバッグで無駄に体力を消耗しています

100 ：デフォルトの名無しさん：2012/10/13(土) 11:18:48.75 .net

馬鹿には無理