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

**デフォルトの名無しさん** · 2012/06/15(金) 01:31:57.88

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

■前スレ
マルチスレッドプログラミング相談室その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・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他特記する事項】

**デフォルトの名無しさん** · 2012/06/15(金) 01:35:25.58

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

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

**デフォルトの名無しさん** · 2012/06/15(金) 03:59:42.18

>>1 乙

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

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

**デフォルトの名無しさん** · 2012/06/15(金) 16:15:07.07

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

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

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

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

**デフォルトの名無しさん** · 2012/06/15(金) 18:14:50.61

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

**デフォルトの名無しさん** · 2012/06/15(金) 18:54:01.14

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

**デフォルトの名無しさん** · 2012/06/15(金) 19:08:46.12

時分割でがんばれ

**デフォルトの名無しさん** · 2012/06/15(金) 21:41:34.19

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];

**デフォルトの名無しさん** · 2012/06/16(土) 12:26:31.55

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

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

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

**デフォルトの名無しさん** · 2012/06/16(土) 12:48:12.18

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

**デフォルトの名無しさん** · 2012/06/16(土) 16:27:05.54

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

**デフォルトの名無しさん** · 2012/06/16(土) 16:52:50.21

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

**デフォルトの名無しさん** · 2012/06/16(土) 16:54:32.86

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

**デフォルトの名無しさん** · 2012/06/16(土) 17:00:15.54

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

**デフォルトの名無しさん** · 2012/06/16(土) 17:19:32.25

ロックフリー！

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

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

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

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

**デフォルトの名無しさん** · 2012/06/16(土) 22:25:28.46

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

4 · 2012/06/16(土) 23:07:53.93

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

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

**デフォルトの名無しさん** · 2012/06/16(土) 23:18:15.13

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

**デフォルトの名無しさん** · 2012/06/17(日) 02:24:44.41

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

**デフォルトの名無しさん** · 2012/06/17(日) 02:28:46.34

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

**デフォルトの名無しさん** · 2012/06/17(日) 03:56:01.16

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

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

**デフォルトの名無しさん** · 2012/06/17(日) 04:08:44.71

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

**デフォルトの名無しさん** · 2012/06/17(日) 06:28:14.10

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

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

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

**デフォルトの名無しさん** · 2012/06/17(日) 14:48:00.38

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

**デフォルトの名無しさん** · 2012/06/17(日) 19:02:58.50

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

**デフォルトの名無しさん** · 2012/06/17(日) 20:27:37.75

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

**デフォルトの名無しさん** · 2012/07/06(金) 19:30:56.61

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

**デフォルトの名無しさん** · 2012/07/06(金) 19:38:42.21

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

**デフォルトの名無しさん** · 2012/07/06(金) 19:45:56.15

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

**デフォルトの名無しさん** · 2012/07/06(金) 19:58:44.83

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

**デフォルトの名無しさん** · 2012/07/06(金) 20:28:22.95

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

**デフォルトの名無しさん** · 2012/07/06(金) 22:01:45.18

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

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

**デフォルトの名無しさん** · 2012/07/06(金) 22:04:26.89

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

**デフォルトの名無しさん** · 2012/07/21(土) 14:53:22.69

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

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

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

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

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

pthread_cond_broadcast(&cond);

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

**デフォルトの名無しさん** · 2012/07/21(土) 14:57:02.99

馬鹿には無理

**デフォルトの名無しさん** · 2012/07/21(土) 15:18:21.14

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

**デフォルトの名無しさん** · 2012/07/21(土) 15:33:58.32

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

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

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

**デフォルトの名無しさん** · 2012/07/21(土) 15:42:20.05

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

**デフォルトの名無しさん** · 2012/07/21(土) 15:49:59.71

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

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

ありがとうございました

**デフォルトの名無しさん** · 2012/07/21(土) 16:06:39.87

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

**デフォルトの名無しさん** · 2012/08/25(土) 18:20:47.36

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

**デフォルトの名無しさん** · 2012/08/26(日) 08:54:03.71

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

**デフォルトの名無しさん** · 2012/08/26(日) 09:32:08.49

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

**デフォルトの名無しさん** · 2012/08/26(日) 09:34:18.81

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

そもそも >>42 が

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

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

**デフォルトの名無しさん** · 2012/08/26(日) 09:57:42.57

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

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

**デフォルトの名無しさん** · 2012/09/01(土) 15:54:33.37

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

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

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

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

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

**デフォルトの名無しさん** · 2012/09/01(土) 15:58:04.54

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

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:04:51.98

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:11:29.80

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:12:43.77

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:16:42.15

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:27:35.25

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

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

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:29:03.73

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

**デフォルトの名無しさん** · 2012/09/01(土) 16:32:16.93

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

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

**デフォルトの名無しさん** · 2012/09/05(水) 01:11:52.99

初心者の質問です

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;

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

**デフォルトの名無しさん** · 2012/09/05(水) 04:17:50.83

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

**デフォルトの名無しさん** · 2012/09/05(水) 06:16:48.24

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

**デフォルトの名無しさん** · 2012/09/05(水) 08:13:29.83

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

**デフォルトの名無しさん** · 2012/09/09(日) 01:13:55.50

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

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

**デフォルトの名無しさん** · 2012/09/09(日) 01:44:44.97

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

**デフォルトの名無しさん** · 2012/09/09(日) 01:51:51.18

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

**デフォルトの名無しさん** · 2012/09/09(日) 07:41:49.96

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

**デフォルトの名無しさん** · 2012/09/09(日) 14:24:32.10

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

**デフォルトの名無しさん** · 2012/09/09(日) 15:54:34.19

そりゃそうだ

**デフォルトの名無しさん** · 2012/09/09(日) 16:30:00.96

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

**デフォルトの名無しさん** · 2012/09/12(水) 00:03:54.96

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

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

**デフォルトの名無しさん** · 2012/09/12(水) 07:22:51.47

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

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

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

**デフォルトの名無しさん** · 2012/09/22(土) 01:53:58.20

>>69
InterlockedExchangePointerは？

**デフォルトの名無しさん** · 2012/09/29(土) 20:38:32.52

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

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

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

**デフォルトの名無しさん** · 2012/09/29(土) 20:49:37.13

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

**デフォルトの名無しさん** · 2012/09/29(土) 21:08:56.80

>>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
はい

**デフォルトの名無しさん** · 2012/09/30(日) 00:03:39.72

>>64
javacやcscじゃね

**デフォルトの名無しさん** · 2012/09/30(日) 00:12:53.41

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

**デフォルトの名無しさん** · 2012/09/30(日) 00:30:58.05

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

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

**デフォルトの名無しさん** · 2012/09/30(日) 00:56:39.75

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

**デフォルトの名無しさん** · 2012/09/30(日) 01:05:56.81

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

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

**デフォルトの名無しさん** · 2012/09/30(日) 01:13:58.15

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

**デフォルトの名無しさん** · 2012/09/30(日) 01:14:33.03

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

**デフォルトの名無しさん** · 2012/09/30(日) 01:21:19.22

>>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を使うとメモリバリアも面倒をみてくれるらしい…

**デフォルトの名無しさん** · 2012/09/30(日) 01:26:29.84

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

**デフォルトの名無しさん** · 2012/09/30(日) 01:27:48.80

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

**デフォルトの名無しさん** · 2012/09/30(日) 02:22:23.12

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

**デフォルトの名無しさん** · 2012/09/30(日) 13:33:02.65

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

**デフォルトの名無しさん** · 2012/09/30(日) 13:35:58.01

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

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

**デフォルトの名無しさん** · 2012/09/30(日) 14:26:20.27

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

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

**デフォルトの名無しさん** · 2012/09/30(日) 15:13:14.28

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

**デフォルトの名無しさん** · 2012/09/30(日) 15:25:27.37

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

**デフォルトの名無しさん** · 2012/09/30(日) 16:54:17.48

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

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

**デフォルトの名無しさん** · 2012/09/30(日) 17:01:09.98

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

そこまでして、

そこまでしても

**デフォルトの名無しさん** · 2012/09/30(日) 21:04:28.14

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

**デフォルトの名無しさん** · 2012/09/30(日) 21:20:03.98

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

**デフォルトの名無しさん** · 2012/09/30(日) 22:09:45.89

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

**デフォルトの名無しさん** · 2012/09/30(日) 23:24:16.01

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

**デフォルトの名無しさん** · 2012/09/30(日) 23:53:26.29

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

**デフォルトの名無しさん** · 2012/10/01(月) 00:06:38.53

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

**デフォルトの名無しさん** · 2012/10/01(月) 07:53:47.16

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

**デフォルトの名無しさん** · 2012/10/12(金) 23:18:24.02

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

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

**デフォルトの名無しさん** · 2012/10/13(土) 11:18:48.75

馬鹿には無理

**デフォルトの名無しさん** · 2012/10/13(土) 13:05:32.66

>>99
排他処理、スレッドモデルと実装を勉強すれば

ビギナーには無理と思うが

**デフォルトの名無しさん** · 2012/10/13(土) 18:57:49.84

>>99
もうそこは、共有している資源と mutex の一覧表作って、地道に設計してレビューで
確認するしかない。

imagix とか確認を支援するツールはあるけど。

**デフォルトの名無しさん** · 2012/10/13(土) 22:12:39.46

>>101
やんないと、他に仕事ないんで・・・・

>>102
かなり頭がよくないと、サラリと正しいコード書けないですよね（棋士的な意味の頭のよさ）
そうか、地道にやるしかないのか(´・ω・｀)

・・・売り物なんですねimagix
自分の担当業務以外にも使えそうなので、ちょっとチーム内に紹介してみます

とりあえず、今の自分のレベルでミスりやすいところを正しく実装するための比喩をいくつか考案中です
↓
例１
スレッド間同期は、キャッチボール
ボールを受け取る側は、しゃがんでいないとボールをキャッチできない

例２
スレッド再開時の手順は、競馬のスタートと同じ
①ゲートを閉じる（送信側mutexロック）
②馬がゲート前に並ぶ（受信側wait）
③ファンファーレが鳴る（signal）
④ゲートが開く（送信側mutex開放）

**デフォルトの名無しさん** · 2012/10/13(土) 23:51:02.32

mutexなんか使わずfuture、promisで凌げ

**デフォルトの名無しさん** · 2012/10/14(日) 17:05:55.79

>>103
転職したほうがよくね
ハロワ通いでもしてみたら

**デフォルトの名無しさん** · 2012/10/14(日) 18:33:06.95

まず10年間C++を勉強しろ

**デフォルトの名無しさん** · 2012/10/14(日) 20:43:53.62

>>106
Ｃ＋＋関係ないやん

**デフォルトの名無しさん** · 2012/10/15(月) 01:03:58.39

>>103
比喩を作ることができるならすでに理解できてるんじゃないの？ってことで、
結局比喩は不要だよねって流れにならないのかな。

**デフォルトの名無しさん** · 2012/10/15(月) 09:17:51.40

結局無理てことか、初心者というより基本が

**デフォルトの名無しさん** · 2012/10/21(日) 14:23:48.88

>>103
とにかくソースコードをきれいに書け
そうすれば、ソースコードが間違いを教えてくれる

**デフォルトの名無しさん** · 2012/10/21(日) 14:42:59.60

>>110
> そうすれば、ソースコードが間違いを教えてくれる

おっ、なんか響きがいい言葉だな。

**デフォルトの名無しさん** · 2012/10/21(日) 23:06:50.68

Joel on softwareの和訳ページ『間違ったコードは間違って見えるようにする』
を紹介しようと思ったが今ちょっと繋がらないようなので原文で読んでちょ↓↓↓
http://www.joelonsoftware.com/articles/Wrong.html

**デフォルトの名無しさん** · 2012/10/26(金) 20:45:55.33

教えてください

g++でコンパイルしたプログラムのプロファイリング、特にスレッドの動作の
効率を見たいのですが、Linux環境で使える定番のフリーツールはないでしょうか？

**デフォルトの名無しさん** · 2012/10/28(日) 11:59:56.78

gdb

**デフォルトの名無しさん** · 2012/10/28(日) 21:28:29.42

ﾏ
ｼﾞ　ﾊ ,,ﾊ
ﾃﾞ　(；ﾟ◇ﾟ)z
!?

**デフォルトの名無しさん** · 2012/12/05(水) 09:54:15.94

プロファイラでわかるのはどの部分が処理時間の何%を使ってるか
ぐらいであって、スレッドの動作効率なんていう個人の価値観みたい
なものは測定できんだろ。

**デフォルトの名無しさん** · 2012/12/31(月) 15:20:38.31

C#です。
C#ではローカル変数にvolatileを付けられませんが
以下の場合、最適化でスレッドの変更が反映されない場合はありますか?

var init = new ManualResetEventSlim(false);
int val = 0;
var t = new Thread(() =>
{
　val = …; // valに何らかの値を入れる
　init.Set(); // valを初期化したことを知らせる
　　　　：
　// スレッドの処理が続く
};

t.Start();
init.Wait(); // スレッドでvalが初期化されるまで待つ
// valを使う。スレッドでの変更が反映されている?

**デフォルトの名無しさん** · 2012/12/31(月) 16:48:21.02

あります

**デフォルトの名無しさん** · 2012/12/31(月) 19:09:35.15

>>118
どういった理由でしょうか?

http://www.albahari.com/threading/part4.aspx
>The following implicitly generate full fences:
>Setting and waiting on a signaling construct

という記述を見つけたのですが、これによれば
valへの書き込みをinit.Set()より後に、valからの読み込みをinit.Wait()より前に
という事は行われないように思えるのですが。

**デフォルトの名無しさん** · 2013/01/01(火) 04:47:40.84

判ってるのに質問するなボケが

**デフォルトの名無しさん** · 2013/01/01(火) 12:37:44.23

それを否定されたから理由を聞いてるんじゃないのか

**デフォルトの名無しさん** · 2013/01/04(金) 04:09:28.62

C#が自ら自身の仕様を質問すること自体が。
まぁ、人間だって自身についてどれだけ知っているか怪しいもんだが。

**デフォルトの名無しさん** · 2013/01/05(土) 12:19:18.18

>>96
の発言で思い出した。
GCDといえば、最近WindowsとLinuxにも移植されたっぽいんだよね。
http://opensource.mlba-team.de/xdispatch/docs/current/index.html

pThreadとかWin32スレッドをローレベルで使うよりお手軽な気がする。
ちょっと試してみるわ。

**デフォルトの名無しさん** · 2013/01/05(土) 18:17:06.97

123だけど、
XDispatchだが、Windowsであっけなく使えた。
こりゃいいぜ。Win、Mac、Linuxで同一ソースでGrand Central Dispatchが使える。
マルチスレッドプログラミング新時代到来って感じだw

**デフォルトの名無しさん** · 2013/01/08(火) 19:15:30.57

XDispatchの導入記事を書いてみた。
https://docs.google.com/document/pub?id=1miIRZh8QteYzjIiU7GjcGSshTp470qHbRQUh0wf12Sw

突っ込みどころあったらご指摘よろ。

**デフォルトの名無しさん** · 2013/01/08(火) 20:13:02.13

libdispatch + α、って感じなのか

**デフォルトの名無しさん** · 2013/01/09(水) 01:22:43.52

>>126
そうみたい。
基本的にはマルチプラットフォームでやりたい場合は${ ~ }の記法とautoを使えばオッケー。
他にも標準のlibdispathには無い機能とか、Qtユーザー向けのQtDispatchとかあるみたいだけど、そこまではまだ調べられてない。
時間があったらもっと調べてみて、追記してみるよ。

**デフォルトの名無しさん** · 2013/01/30(水) 19:59:09.23

Win32でのプロセス間リソース共有の仕方で悩んでます

1. ポーリング＝Mutexで保護された共有リソースの変更を常に監視
2. サーバー(orクライアント)スレッドでEvent監視+Mutexで共有リソースを保護

余計なCPUリソースを食うのはどちらなんでしょうか？定性的な評価と理由を教えてください
（定性的な評価＝プロファイルで調べろは無しでお願いします）
自分は「重さ：Mutex>>>>Event>>>>>>>CriticalSection」というイメージがあるので、
2のマルチスレッドのコンテキストスイッチの重さを考慮しても1の方が重いのではないかと考えています

**デフォルトの名無しさん** · 2013/01/30(水) 20:42:56.62

(ﾟДﾟ)ﾊｧ?
Mutexを奪い合えばいいだけだし。

**デフォルトの名無しさん** · 2013/01/30(水) 21:22:17.63

Event vs. Pollingは宗教戦争

**デフォルトの名無しさん** · 2013/01/30(水) 21:52:45.99

何もすることがなきゃ寝て待ってればいいだけ
何かしたけりゃイベント来るまでしてればよかろう

**デフォルトの名無しさん** · 2013/01/31(木) 08:42:39.84

Mutexが重いんじゃなくてポーリングが重いんだろ
イベントやメッセージ等の非同期通知が使えるなら、そっちのほうが軽いのは当然

**デフォルトの名無しさん** · 2013/01/31(木) 22:24:51.03

>>128
> Win32でのプロセス間リソース共有の仕方で悩んでます
winすれで聞いたら
> 余計なCPUリソースを食うのはどちらなんでしょうか？定性的な評価と理由を教えてください
人から聞いたことを信じるの？

**デフォルトの名無しさん** · 2013/02/01(金) 07:29:56.93

効率を気にする香具師が2chで質問するとかもうね

**デフォルトの名無しさん** · 2013/02/17(日) 17:37:32.78

>>79ではx86、x64では（P6～）
　RAR WAR WAW RAW
　　×　 × 　 × 　 × 　　... × 順序の逆転が起きる WAR ... Write after Read (書いてから読む)

となってるけど>>81のMSDNでは WAR のみ逆転が起こる、書いてる。
　RAR WAR WAW RAW
　　○　 × 　 ○ 　 ○

どっちが正しいのでしょうか？

あと、MSDNの英語の原文はこっちだけど
http://msdn.microsoft.com/en-us/library/windows/desktop/ee418650(v=vs.85).aspx
Reads moving ahead of writes の訳が
「読み取りを書き込みの先に移動する」
「書き込みの前に読み取りを移動」
と2回出てきて紛らわしい。

write
...
read

この順番が逆になることあり、てことだよね？

**デフォルトの名無しさん** · 2013/02/17(日) 21:17:44.97

>>135 それ RAW じゃね

シングルスレッドのメモリ命令は RAW (対象アドレスが被らない) と
WAW (命令による) の特定ケースを除いて命令順通り、
マルチスレッドの各スレッド間では、全パターンに入れ替えの可能性あり。

たぶん MSDN の記載は誤解を招くかと。
こちらの根拠は以下の Volume 3A, Chapter 8.2

Intel 64 and IA-32 Architectures Software Developer's Manuals
ttp://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

write -> 0x1000
...
read -> 0x2000

と明らかに異なる場所へのアクセスであり、... の間に他のメモリアクセスが
無ければ、read を write の前に持ってきても結果は変わらないはず。

**デフォルトの名無しさん** · 2013/02/18(月) 21:54:23.31

>>135
WARはレジスタリネーミングと同じだよ。
上書きするなら依存関係が切れるので命令の実行順序は入れ替え可能になる。
結果を内部で保持しておいて後で書き出す。
そして実際のメモリの内容は命令の順序通りの結果になる（ならなかったら大変）。

でいいかと。

**137** · 2013/02/18(月) 22:30:08.38

>>137の補足しとくと、同一プロセッサでも異なるアドレスだとリオーダ可能なので
順序が重要な場合はメモリフェンスが必要になる。
別のプロセッサ間でもリオーダ可能ということになる。

別のプロセッサとの同じメモリに対するアクセス順序はタイミング次第で複雑なので
必要に応じてロックプレフィックスを使う。

**デフォルトの名無しさん** · 2013/02/18(月) 23:53:52.86

>>135
MSDNのほうが正しい。
昔はIntelのdeveloper manualの記述が曖昧だったこともあり、
間違った解説が結構ある。

>>136-138
マルチスレッドでもRAW以外は入れ替わらないよ。

**デフォルトの名無しさん** · 2013/02/19(火) 07:57:34.41

>>139
キャッシュラインがコピーされた状態ではRARの順番は替わりうると思うけど
RAW自体は入れ替わらないんじゃないかな。
実際のWriteの前にReadが割り込む可能性があるけど、それはタイミング次第ってことで。

**デフォルトの名無しさん** · 2013/02/19(火) 09:15:14.16

lockプリフィックス使うんじゃあ

**デフォルトの名無しさん** · 2013/02/23(土) 20:04:20.23

>>139
そうか、マルチスレッドでもリオーダは無いな。他から割り込まれる可能性があるだけだ。

**135** · 2013/02/23(土) 23:41:17.41

>>136-142さん、さんくすでした。
MDSNが正しかったのですか。

＞それ RAW じゃね
でした。コードの順番と英語表記は逆になるんですよね。誤解してました・・・。

この辺を勉強する本とかないでしょうか？
「The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで」
は読んでみたのですがロックレスアルゴリズムの原理だけでCPUごとの実装は
なかったのであまり役にたたなかったです。

**デフォルトの名無しさん** · 2013/02/24(日) 10:17:55.94

ハードウェアを実装するとなったらそれこそ本一冊どころではすまないだろうけど、
データの同期に関しては何が危険でどうすれば安全に扱えるかが区別できればいいんじゃない？
だから本を買って読むほどでもないような。

CPU内の順序はOut of Orderが関係していて、CPUは可能な限り速く実行しようとするから
順番が入れ替わってしまうってことで、それをコントロールするのにメモリバリア命令がある。
アセンブラの最適化にも関係してるから、プロセッサの最適化マニュアルとかも参考になるかも。

マルチプロセッサではキャッシュコヒーレンシやMESIプロトコルとかの概略を知ってればいいんじゃないかな。
他のプロセッサに割り込まれて困る部分にはlockで保護するとか。

**デフォルトの名無しさん** · 2013/02/26(火) 14:50:30.35

Java の資料だけど「コンパイラ開発者のためのJSR133クックブック」ってのはどう？

**デフォルトの名無しさん** · 2013/02/27(水) 12:54:04.48

>>145
邦訳版はダメ。
肝心のアーキテクチャ毎の表などが古いままで間違っている。

**デフォルトの名無しさん** · 2013/02/27(水) 23:21:29.29

RafterWってシングルスレッドなら絶対安全？
途中で実行cpuが変わってもosが面倒見てくれるから気にする必要はないってこと？
実行cpuが変わることあるかしらないけど

まぁ普通にコード書いてて入れ替わる訳ないから大丈夫か

**デフォルトの名無しさん** · 2013/03/02(土) 16:47:32.29

>>147
> まぁ普通にコード書いてて入れ替わる訳ないから大丈夫か

普通に入れ替わるだろ。
切替前に読み込んだ情報は、違う CPU でもちゃんと復帰するから
問題ないはず。

**デフォルトの名無しさん** · 2013/03/03(日) 20:26:49.52

>>148
書き方が悪かった。

マルチプロセッサの環境でシングルスレッドのコードを実行してて、
実行CPUが変わったとしても読み書き順が入れ替わらないでしょう？

そこはOSがプロセス切り替え時に勝手にバリアをかけてるはずだよね？ってこと

**デフォルトの名無しさん** · 2013/03/03(日) 20:30:18.24

>>149
ああそういうことか、それは大丈夫だと思うよ。

◆0uxK91AxII · 2013/03/03(日) 22:58:29.83

バーリアー！平気だもーん！

**デフォルトの名無しさん** · 2013/03/04(月) 01:43:54.42

MemoryBarrier()の実装ってx86では単なるxchgなのな。
なんでmfence使ってないのだろう？速度では大差ないってことなのかな。

MemoryBarrier macro (Windows)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684208

↓はC++11のスレッドライブラリ作った作者の本らしいんだが、pdfで全部公開されてる。
ありがたいのでだけどメモリフェンスは std::memory_order_acquire みたいな一般命令で
隠すようなコードしか書いてない。

C++ Concurrency in Action: Practical Multithreading
http://www.amazon.co.jp/dp/1933988770/

**デフォルトの名無しさん** · 2013/03/04(月) 09:03:05.32

マルチコアでないマルチプロセッサ構成で、
外部キャッシュや主記憶のシステムコントローラが、
ＣＰＵ本体より弱いメモリモデルを採用してる場合に意味を持ってくる。
Windowsではこうゆうハードウェア構成は想定してないはず。

**デフォルトの名無しさん** · 2013/03/04(月) 10:40:54.32

>>153
違うよ。全然違うよ。
とりあえず、これでもじっくり読め。
msdn.microsoft.com/ja-jp/magazine/jj883956.aspx

**デフォルトの名無しさん** · 2013/03/04(月) 11:45:37.38

ところでmfenceは何でSSE2の制御命令に分類されてるの？

**デフォルトの名無しさん** · 2013/03/04(月) 23:37:29.77

>>152
MemoryBarrier()はx64でもsfence/mfence使ってないな。
やっぱり処理速度の関係だろうか。
まるでenter命令並みに使えない。

x86
0000b　87 04 24　xchg　DWORD PTR _Barrier$66624[esp+4], eax
x64
0003a　f0 83 0c 24 00 lock or DWORD PTR [rsp], 0

**デフォルトの名無しさん** · 2013/03/11(月) 14:35:12.41

>>155
xFENCE命令はMOVNTPS, MOVNTPD,などのNon Temporal転送命令向けの機能で、
この系統の命令だけx86のメモリモデルに従わないので専用のFENCE命令が必要となった。
このうちLFENCEとMFENCEは普通のx86命令にも効果があるが、
パフォーマンスがxchgに劣る。

**デフォルトの名無しさん** · 2013/03/11(月) 15:38:43.70

なんでxchgがバリアとして使えるの？

**デフォルトの名無しさん** · 2013/03/11(月) 17:50:17.45

メモリに対するxchgは自動的にlockを伴う

**片山博文MZパンク** ◆0lBZNi.Q7evd · 2013/06/18(火) 23:59:01.86

確率的にいつ終わるかわからない時間の掛かる処理をマルチスレッドを使って複数同時に
実行させると、シングルスレッドよりも早い時間で終わる確率が高くなると思うが、これについて貴様らはどう思う？

**片山博文MZパンク** ◆0lBZNi.Q7evd · 2013/06/19(水) 00:04:03.77

ちなみにクロスワード自動作成ソフトを作ってますっ

**デフォルトの名無しさん** · 2013/06/19(水) 01:02:30.98

辞書ひく時間が糞長いから、マルチスレッドやっても大して変わらない

**デフォルトの名無しさん** · 2013/06/19(水) 06:32:32.99

>クロスワード自動作成ソフト

どこらへんを並列化できるのん？

**デフォルトの名無しさん** · 2013/06/19(水) 09:30:45.19

バックトラック乱れ打ちじゃねーの

**デフォルトの名無しさん** · 2013/06/20(木) 07:49:26.95

同じレスを各板に乱れ撃ちする作業だろ？

**デフォルトの名無しさん** · 2013/06/20(木) 15:25:09.57

マルチスレッドにしたら５～８時間に１回エラーが出るようになった。でもデバックできないよorz

**デフォルトの名無しさん** · 2013/06/20(木) 20:17:10.50

つログ

**デフォルトの名無しさん** · 2013/06/20(木) 22:19:34.34

同期もわかってないのにマルチスレッドにするからだ。

**デフォルトの名無しさん** · 2013/06/20(木) 22:26:19.30

同期とったら並列の意味がなくなりそうでためらうときがあるな
待ち合わせキューにするくらいなら順番に処理した方がましな気がする

**デフォルトの名無しさん** · 2013/06/21(金) 00:07:54.88

つスーパースカラー

**デフォルトの名無しさん** · 2013/06/21(金) 00:28:22.79

粒度変えりゃいいじゃん

**デフォルトの名無しさん** · 2013/06/21(金) 04:34:35.98

マルチスレッドって自作できるんですか？
以前nyの書籍を読んだときに、開発者の人がマルチスレッドを自作したと書いてたような気がするのですが
C言語でも自作できるんですか？

**デフォルトの名無しさん** · 2013/06/21(金) 04:48:19.55

マルチスレッド・マルチタスクで動いているように見せることは出来る。

並列動作させたい複数の処理を細切れにしてちょっとづつ実行して
グルグル回す。

**デフォルトの名無しさん** · 2013/06/21(金) 15:03:05.45

>>173
タイムシェアリングみたいにやるってことですか

**デフォルトの名無しさん** · 2013/06/21(金) 19:27:29.84

>>174
俺が>>173で書いたのは、タイムシェアリングではなく
ノンプリエンプティブ・マルチタスク。
例えば無限ループ内に3処理 A, B, C があったとして
それらをマルチで実行したければ、それぞれを
A1, A2, A3
B1, B2, B3
C1, C2, C3
などと細切れに分割し、
A1, B1, C1, A2, B2, C2, A3, B3, C3,　A1, ……(無限ループ)
と実行する。

いまでも、組み込みでコントローラやセンサーを制御する小さなCPUは
マルチタスクの能力を持っていないのが当たり前のようにあり、
これでマルチ動作させるのに当たり前のように使われる手法。

**デフォルトの名無しさん** · 2013/06/21(金) 19:38:33.60

スレち

**デフォルトの名無しさん** · 2013/06/21(金) 19:52:56.34

スレチというほどじゃないんじゃない？

OSレベルでスレッドのサポートが無い場合は、
言語ランタイムレベルのグリーンスレッド
タイマー等の割り込みの利用
メッセージポンプのループ利用
NT Fiber

スレッドはないけどプロセスのマルチが出来るなら、
パイプなどでプロセス間通信の利用
といったところかな

**デフォルトの名無しさん** · 2013/06/21(金) 20:25:17.31

俺もスレチじゃないと思う

**デフォルトの名無しさん** · 2013/06/21(金) 20:31:18.12

windows 3.1 を思い出すな

**デフォルトの名無しさん** · 2013/06/21(金) 20:41:54.83

ファイバーってレアすぎ

**デフォルトの名無しさん** · 2013/06/21(金) 22:30:00.37

>>175
win31 のことね

**デフォルトの名無しさん** · 2013/06/21(金) 22:38:33.58

気が早いな
まだ8だぞ

**デフォルトの名無しさん** · 2013/06/21(金) 23:18:56.88

2000があるのに…

>>175をタイムシェアリングだと思ってたな。もう少し勉強しよう。

**デフォルトの名無しさん** · 2013/06/21(金) 23:38:19.83

ファイアー少なくてレアすぎ

**デフォルトの名無しさん** · 2013/06/21(金) 23:40:35.43

広義だと含むのとちゃうかな
おさ～ん的にはTSS(TSO)のホスト端末を思い浮かべるけど

**デフォルトの名無しさん** · 2013/06/23(日) 12:58:55.01

ファイバー使ってみたけど、
フェーズとswitchより
シンプルに書けたよ。

**デフォルトの名無しさん** · 2013/11/22(金) 08:18:08.42

C/C++　で勉強したいのですが、おすすめの書籍などありますか？
もしくは一から学べるようなWebページがあれば教えてください

**デフォルトの名無しさん** · 2013/11/22(金) 09:05:54.07

D の方が良いよ

**デフォルトの名無しさん** · 2013/11/22(金) 13:04:58.77

猫でもわかる

**デフォルトの名無しさん** · 2013/11/23(土) 05:39:10.02

>>188
D のほうが書きやすい？触れたことないのでわからんです
>>189
猫でもわかるは、Web版が俺にはちょっと分かりづらかった記憶が
書籍だとそうでもないのかな

C++のBoostを利用したThreadプログラミングの解説ページがあったので今はそれ見てます

**デフォルトの名無しさん** · 2013/11/23(土) 09:00:39.63

>>190
触ってもいいお

**デフォルトの名無しさん** · 2013/11/23(土) 13:19:59.45

>>191
どれどれ

**デフォルトの名無しさん** · 2013/11/23(土) 13:24:53.59

>>191
ペロペロ

**デフォルトの名無しさん** · 2014/02/23(日) 09:00:04.29

マルチスレッドって自力だとどうやって書くの？

**デフォルトの名無しさん** · 2014/02/23(日) 09:43:27.54

pthread_create()

**ＫＵＳＯＫＯＴＥ** ◆unko./w.Osri · 2014/02/23(日) 10:15:16.84

>>194
std::thread th{
　[]{std::this_thread::sleep_for(std::chrono::milliseconds(3000));}
};
std::printf("うんこ\n");
th.join();

**デフォルトの名無しさん** · 2014/02/24(月) 17:57:18.01

例の金子がny作るときにマルチスレッドは自作したんじゃなかったっけ？

**デフォルトの名無しさん** · 2014/02/24(月) 18:45:47.70

なんとかしてこれを読むと良い
ttp://ci.nii.ac.jp/naid/40000002652

**デフォルトの名無しさん** · 2014/02/25(火) 00:18:34.64

>>197
あれ、シングルスレッドだよ。
Windows3.1みたいな方法で複数のタスク回してる。

**デフォルトの名無しさん** · 2014/02/25(火) 06:43:17.74

小学生がBASICで弾の連射実装してるレベルだろ。

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

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