10/02/21 18:06:11
>>319
Java並行処理プログラミングマジオススメ。
直接同じことは出来なくても、考え方は大いに参考になる。
volatileだけはC++と全くの別物なので注意だけど。
boost.threadのfutureでJavaのExecutorフレームワークに近いことが出来そうだなぁ。
322:デフォルトの名無しさん
10/02/21 18:16:04
>>321
その程度の書籍薦められても困るんだよ
もっとまともな本持って来い
323:デフォルトの名無しさん
10/02/21 18:29:39
>>322
Java並行処理プログラミングでも満足できない貴方には
↓がお勧め。
URLﾘﾝｸ(scholar.google.com)
最先端の研究成果が大量に手に入るぞ。
324:デフォルトの名無しさん
10/02/21 19:01:28
>>322
もっとまともな本があるなら俺も知りたいけどね。
325:デフォルトの名無しさん
10/02/21 23:35:25
並行コンピューティング技法―実践マルチコア/マルチスレッドプログラミング
URLﾘﾝｸ(www.oreilly.co.jp)
326:デフォルトの名無しさん
10/02/22 16:37:56
begintreadexを使ったときはclosehandleを使わないといけないらしいけど
CloseHandle((HANDLE)_beginthreadex());
こんな感じでいいの？
327:デフォルトの名無しさん
10/02/22 16:42:48
beginthreadexが返したハンドルを渡すのかと聞いているのならYES
328:デフォルトの名無しさん
10/02/22 17:44:29
_beginthreadexはなんで整数型で返すんだろう
329:デフォルトの名無しさん
10/02/22 22:11:07
Win32の型を持ち込みたくなかったからじゃないの。
330:デフォルトの名無しさん
10/02/23 00:27:00
意味も無く汚くはしないしな、いくらMSでも
331:デフォルトの名無しさん
10/02/23 00:29:08
void *じゃだめなのか
332:デフォルトの名無しさん
10/02/23 08:52:12
それだと32bitであることを強調できないからやめたんじゃないかな
333:デフォルトの名無しさん
10/02/23 14:32:40
一応今はuintptr_tだしな
まぁ毎度のレガシーの枷なんだろうし、仕方ないっつーか正直どうでもいい
334:デフォルトの名無しさん
10/03/07 15:36:02
どちらかというとマルチコア絡みの質問ですが
テンプレにある該当スレは過疎ってるぽいのでこちらで質問させていただきます
Q1. Windowsはスレッドコンテキスト切替時、汎用レジスタ同様にxmmレジスタを待避/復帰しますか？
主にWindows 7 (32 bit)とWindows 7(64 bit)について知りたいですが、他のも回答いただけると有難いです
Q2. そもそもCore i7のSIMDモジュールってコア毎に独立してますか？
独立してるっぽいけど、確証となるブロックダイアグラムみたいなのがＩｎｔｅｌのドキュメントを漁っても見つからないorz
Q3. Core i7の分岐予測メモリって、コードが共通なら全スレッドで共通？それともスレッドコンテキスト毎にきちんと別統計になるんでしょうか？
Q4. VC(2008)付属ライブラリの数学関数(おそらくコプロセッサを使うはず)はスレッドセーフですか？またそれは/fp:オプションによらず不変？
よろすくおながいしますorz
335:デフォルトの名無しさん
10/03/07 16:24:51
A1: Windows 98, 2000以降はyes
A4: yes
336:デフォルトの名無しさん
10/03/07 16:51:28
A2 コア別でしょう。たぶん。コア間共有なんて設計のほうが難しいと思うよ。
A3 コア別でしょう。たぶん。コア間共有なんて設計のほうが難しいと思うよ。
337:デフォルトの名無しさん
10/03/07 17:32:40
>>326
>CloseHandle((HANDLE)_beginthreadex());
その組み合わせはちょっちまずくね？
URLﾘﾝｸ(msdn.microsoft.com)
にメモリリークが起きると書いてある(ちなみにやねうら本(1)にもそう書いてある)
ExitThread()を明示的に呼ばなくても、スレッド関数を抜けたら同じことのはず
なお、>326の反対(CreateThread()が返したハンドルを _endthread()で開放する)は明白に危険であろうことが上のリンク先から推測できる
(確保されていないメモリを_endthread()が解放しようとするハズ)
338:デフォルトの名無しさん
10/03/07 18:07:36
何のために_beginthread()～_endthread()や_beginthreadex()～_endthreadex()があるかというと
strtol()みたいに、機能的にはマルチスレッド環境下でも動いて欲しいのだが関数仕様的にマルチスレッドと相容れないような
標準関数をマルチスレッド環境でもきちんと動くようにする目的なので(おそらくそのために内部的にスレッド局所記憶を確保している)
そういう類の関数を明示的にも暗黙的にも呼び出さないと誓うならCreateThread()～CloseHandle()で無問題
339:308
10/03/07 18:19:56
ｽﾏｿstortol()じゃなくて問題なのはstrtok()とかlocaltime()とかだった、
340:デフォルトの名無しさん
10/03/07 18:53:55
>>337
_beginthread は起動されたスレッドが終了時にハンドルのクローズを行う。
_beginthreadex は別途CloseHandleする必要がある。その代わり、
スレッドが終了していてもハンドルは有効であり、スレッドの状態を調べることができる。
ここでのリークというのはCRTの作業域のことではなくて
あくまでもスレッドを追跡するためのハンドルのこと。
341:デフォルトの名無しさん
10/03/07 22:27:39
>335, >336
レス㌧クス
A1は実験的にも確認できた(イントリンシック関数が排他を含まないこと、およびxmm0とxmm1を使う関数を64スレッドで呼び出して無問題)
A2はまあそう思う(ダイ写真でSIMDとコアの区別を確認できない＆SIMDの数＜コアの数ではマルチメディア目的に合致しない)
A4についても使用予定関数について実験的に確認できた
A3はちょっち謎
同一コードで記述され、同一コアで走る別スレッド(含HT)の場合どうなるのか？
同一コード条件とそうでない条件(コードをスレッド別コピーとする)とで速度比較すればいいんだろうけども
コードをコピーすると分岐予測以前にトレースキャッシュ容量他の要因で速度低下するかもしれないから実験では精度良くは判断できない鴨
342:デフォルトの名無しさん
10/03/08 00:36:48
pthread_cond_wait状態になるまでに
結構時間かかるのですかね？
以下のようなコードを実効すると
結構頻繁に、別のスレッドがwait状態になる前に
pthread_cond_signalを実効してしまうのですが
必ず、同期取るようにどうしたらいいのでしょうか
thread1
{
while(1){
pthread_mutex_lock(&m);
pthread_cond_wait(&c, &m);
pthread_mutex_unlock(&m);
}
}
main
{
while(1) {
pthread_mutex_lock(&m);
pthread_cond_signal(&c, &m);
pthread_mutex_unlock(&m);
}
}
343:デフォルトの名無しさん
10/03/08 00:39:08
どうやって確認したの？
344:デフォルトの名無しさん
10/03/08 00:45:01
何がしたいのかよくわからんが、
とりあえずmutex取得する前にシグナル発行してたらいかんだろう。
345:デフォルトの名無しさん
10/03/08 00:54:13
thread1がlockするまえにmainがlock->signalしちゃってるとかありそう
346:デフォルトの名無しさん
10/03/09 07:06:51
>>337-338
つーか比較するものが間違ってる
_endthread()/_endthreadex()は作られた側が（必要なら）呼び出すもので
CloseHandleは_beginthread()/_beginthreadex()呼んだ側が呼び出すもの
347:341
10/03/13 23:42:54
自己解決しますた！(いや、多分、だけど
Windowsのスレッドコンテキスト切替は、スレッドが走り続けている場合、どうがんばっても
msオーダー周期(おそらく10 msとか20 msに1回）なので、分岐予測統計の結果がその間に十分安定する(と思われ
だから分岐予測精度を上げるためにコードのコピーをスレッド別に用意しておく、みたいな神経質なことはしなくて宜しい
かと、
348:342
10/03/14 01:04:34
訂正
誤：分岐予測統計の結果がその間に十分安定する(と思われ
正：分岐予測統計の結果が現実的に安定している期間よりも桁違いに長い(と思われ
ニホンゴ、ムズカシイデス、、
349:デフォルトの名無しさん
10/03/14 02:03:43
いやいやいやいや
いまはコア間での話ではなかったのか？
350:デフォルトの名無しさん
10/03/14 08:00:00
またえらい細かいオーダーで削ってるんだなぁ。
PCのWindowsでそこまでカツカツ削っても、すぐに時代変わっちゃうと思うけどなぁ。
他のとこに力入れた方が良くね？
まぁ、トレースキャッシュとか気にしてるから、何か特殊な固定環境向けのガリガリな
チューニングなのかもしれないけど。
俺も低レベルは好きだから、とりあえず触ることで知識と感覚を深めたい、ってんなら
止めないけど。単にバランス感覚の欠けてるケースに見えてしまうが。違ったらすまん。
351:デフォルトの名無しさん
10/03/14 08:19:21
>>349
分岐予測メモリはCore i7の場合物理コアごとに持ってるからスレッドごとに物理コアを違える場合は何も悩む必要はない
問題なのはスレッドの数が物理コア数より多いとか、同一物理コア内でのHTの場合(→341の下から3行目参照)
352:デフォルトの名無しさん
10/03/14 08:30:59
ハッよく考えたら>348-349のロジックじゃあHTの場合が解決してねーじゃんorz
同一コア内で走るHT0とHT1は、ハードウェアレベルで演算ユニット、L1, L2キャッシュ、トレースメモリを奪い合うので
もし仮に分岐予測メモリのタグがアドレスのみから生成され、HT番号では区別されない作の場合問題になりえる
ただしまあ現実的には同じアドレスに配置された同じ条件分岐命令が
1. HT0とHT1でほぼ同時に（=分岐予測結果の平均寿命(おそらく数μsec)オーダーの時間差内に）実行されるという状況が
2. 片方は分岐、片方は非分岐で
3. 無視し得ない頻度で反復される
というケースでのみ問題だが
>>350
というわけでWindows非依存な話
353:デフォルトの名無しさん
10/03/14 08:32:37
>>352
いや本人がWindows7を対象にしてるって最初に言ってるから
354:デフォルトの名無しさん
10/03/22 00:57:55
>>342
亀だが、それは条件変数の使い方を間違えとる
いきなり無条件でcond_waitで待ってはいかん
cond_waitは、あくまで「共有条件が望む状態になっていない時」に使うものだ
cond_wait時に指定するmutexは、その「共有条件」をテストするためのものだ
でもってcond_signalやcond_broadcastは、共有条件の変更があったことを通知して、共有条件の再テストの機会を与えるものだ
なお、cond_signal, cond_broadcastの実行そのものには、mutexの取得は必要ない
JMなんかのpthread_cond_initのmanページを見て、使用例を確認すると良い
355:デフォルトの名無しさん
10/03/27 11:48:41
pthreadの記事を見つけたので読んでたら、
なんかコメントで色々指摘が入ってるんだけど、どうなの？
URLﾘﾝｸ(codezine.jp)
356:デフォルトの名無しさん
10/03/27 15:08:07
ここのコメント欄みづらいんだよね
最初の「必要以上に複雑になってる」という指摘は同意。
この記事って、バグのあるコードをだんだん直していくっていう
流れだけど、そもそもタイトルの条件変数関係ないバグだし、
修正内容も、なんか泥沼に入っていくような感じ
その後のやりとは、この二人にしか分からないどうでもいいことについて、
どうでもいいやりとりしてるように見えた。
357:デフォルトの名無しさん
10/03/27 15:20:18
>>338
これはわかりやすい！
358:デフォルトの名無しさん
10/03/29 23:05:41
「Java並行処理プログラミング」が増刷してる
359:デフォルトの名無しさん
10/04/18 10:57:03
va_argsってスレッドセーフですか？
360:デフォルトの名無しさん
10/04/18 21:21:11
va_list を自動変数やTLBに置いていれば、va_listをスレッド間で共有しない限りは、スレッドセーフだと思うぞ。
361:デフォルトの名無しさん
10/04/18 22:11:15
>>360
嘘ついちゃだめ
va_listはプロセスで１つだけしか持てないから
スレッドセーフじゃないよ
362:デフォルトの名無しさん
10/04/19 00:34:37
ボナンザ８コア対応を１６コア対応にする方法を教えて下さい。
363:デフォルトの名無しさん
10/04/19 06:51:44
スレッドセーフかどうかってのはcrtのソース見ないと判断付かないって認識でおkっすか？
364:デフォルトの名無しさん
10/04/19 07:04:05
>>361
適当ぶっこくなカス
365:デフォルトの名無しさん
10/04/19 07:18:38
>>364
じゃあ証明してくれよ
できないだろw?
366:デフォルトの名無しさん
10/04/19 07:28:20
>va_listはプロセスで１つだけしか持てない
367:デフォルトの名無しさん
10/04/19 07:59:36
それとスレッドセーフの話にどんな関係が？
368:デフォルトの名無しさん
10/04/19 08:31:37
>>365
簡単。
va_listはプロセスで複数もてるから
スレッドセーフ
369:デフォルトの名無しさん
10/04/21 11:18:50
すみません、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"
);
370: ◆0uxK91AxII
10/04/21 15:37:33
>>369
方法はあるけど、物凄くマヌケで無意味だから誰もやらない。
371:デフォルトの名無しさん
10/04/21 19:01:35
スレッドとかの切り替えを自前で用意するとか
372:369
10/04/22 09:40:25
いろいろと試してみたのですが、マヌケな方法しか思いつきませんでした。
（スピンを何回かしたら、nanosleepを使うとか）
pthreadのライブラリのソースを見てみると、futexのシステムコールが呼ばれているようですね。
OpenMPで生成したスレッドの中で実行される関数間でスレッドの同期をとりたかったのと、
せっかくOpenMPを使っているから、
pthreadとか使いたくなかったので自前のspin_lockを作ってみました。
マヌケな質問をしてすみませんでした。
373:デフォルトの名無しさん
10/05/08 03:22:14
ヒント：スピンロックを使わない
374:デフォルトの名無しさん
10/05/09 22:01:03
Win32でスレッド間のイベント通知をやりたいんですが
2つのスレッドが同時にそれぞれSetEvent(), ResetEvent()を呼び出した場合の動作って定義されてるんでしょうか？
やっぱりクリティカルセクションで囲ってやらないとまずいですか？
375:デフォルトの名無しさん
10/05/09 22:39:08
>>374
囲む必要は無い。
376:デフォルトの名無しさん
10/05/10 08:17:54
>>375
ありがとうございます。
377:デフォルトの名無しさん
10/05/10 20:41:23
イベントオブジェクト自体の動作には問題ないけど、
使い方ミスりやすいから十分気を付けた方がいいよ。
378:デフォルトの名無しさん
10/05/10 23:08:00
プロのコードではイベントオブジェクトは使われない
379:デフォルトの名無しさん
10/05/10 23:37:24
配布したときに問題が出るからな
380:デフォルトの名無しさん
10/05/11 03:50:40
どんな？
381:デフォルトの名無しさん
10/05/12 22:45:33
無名にすれば他のプロセスと衝突することも無いし、kernel32.dllだから別にDLLも不要だし問題が思いつかないな
382:デフォルトの名無しさん
10/05/13 07:37:01
なんか勘違いしてんだろ
383:デフォルトの名無しさん
10/05/16 21:15:32
wait-freeなキューの実装を可能にするのに必要な不可分操作ってどんなんですか？
384:デフォルトの名無しさん
10/05/16 23:08:56
候補となる不可分操作には何があるの？
385:383
10/05/16 23:57:41
>384
JAVAのConcurrentLinkedQueueだとCASをつかってるってことしか知りませんが..
386:デフォルトの名無しさん
10/05/18 00:45:56
wikiによるとcasみたいだね
URLﾘﾝｸ(ja.wikipedia.org)
387:デフォルトの名無しさん
10/05/20 23:12:58
スレッド間のヘルスチェックに定番な方法ってあるのでしょうか？
・マスターなスレッドAが外部変数にスレッド数分bit1を立てる
・B以降のスレッドは、自分に対応するbitを落とす
・一定時間、0じゃなかったら誰かが止まってるのでNG
とかすると、sem_wait()で普段寝ている人(これはその時だけ起こせばいい？)や、
recvやselectで待ってる人の確認はできない。。
388:デフォルトの名無しさん
10/05/21 00:00:00
スレッドのヘルスチェックって要るのかな？プロセス間だったら必要かも知れなけど。
389:デフォルトの名無しさん
10/05/21 00:05:09
大事な役割を持ったスレッドが刺さってないか確認したいんじゃないの
390:デフォルトの名無しさん
10/05/21 01:47:25
タイムアウト指定して待ちっぱなしにならないようにするのが基本
391:デフォルトの名無しさん
10/05/21 18:56:29
ワーカースレッドとＵＩスレッド分けたとき、時間のかかる作業を
ワーカースレッドがしているとき、ＵＩスレッドはどうしているべきでしょうか
今は終わるのを待たずに終わるまでデータ変更の起こる操作を禁止しています
でもそれだとウィンドウ動かせるくらいしかメリットがないので考え中です
392:デフォルトの名無しさん
10/05/21 19:03:15
>>391
俺は[中止]ボタンが押されるのを待つか、タイマーで定期的に終了したかどうか
チェックしてる。あとプログレスバー表示。
393:デフォルトの名無しさん
10/05/21 19:49:50
ボタンを禁止にしたりキャンセルを受け付けたり面倒だよな
それとプログレって、量的な変化ならいいが、
手続き的な進行表示には不向きだよな
394:デフォルトの名無しさん
10/05/21 20:05:26
全体量がわからないやつはつらいよね
\-/-\-...ってやつが好きｗ
395:デフォルトの名無しさん
10/05/21 21:03:40
経過表示なら1/n「(説明)」～n/n「完了」でいいと思うんだ
396:デフォルトの名無しさん
10/05/24 23:34:30
progress_display「呼んだ？」
397:デフォルトの名無しさん
10/05/25 09:11:50
いや、全然呼んでないよ
398:デフォルトの名無しさん
10/06/26 14:48:12
マルチスレッド・アプリケーション開発のためのインテル・ガイド
URLﾘﾝｸ(www.xlsoft.com)
399:デフォルトの名無しさん
10/06/27 14:54:02
>>391
おれはその処理に関連するメニューだけロック(選択不可とか無視とか)して他の操作は許可してる
処理が終わったら通知ポップアップ
処理状況なんかはモーダレスじゃないプログレスバーかステータスバー表示
400:デフォルトの名無しさん
10/06/27 15:01:41
>>393
でも長時間うんともすんとも言わないと不安になるからそういう場合は一秒に一ブロックぐらい進むプログレスバー繰り返してる
中止は処理スレッドに定期的に中断フラグチェックさせてプログレスバーダイアログのOnClose/OnCancelで終了フラグOn+WaitForSingleObjectさせればOK
401:デフォルトの名無しさん
10/07/02 23:09:47
URLﾘﾝｸ(blogs.wankuma.com)
なんかえらい絡まれてるくらい突っ込まれてるみたいなんだけど
やっぱりこの記事おかしいの？
それともコメントの方がおかしい？
402:デフォルトの名無しさん
10/07/02 23:28:25
>>401
バブルソートを題材にするとか並列化のサンプルとして適切じゃないというかフェアじゃないというか、あえてそれを選ぶのはなぜ？って話でしょう。
403:デフォルトの名無しさん
10/07/02 23:40:12
>何でもかんでも並列化すれば、等しく速くなるわけではない
記事の結論には同意だけど記事書いてるひとはアホ
404:デフォルトの名無しさん
10/07/03 02:56:46
>>403
同意だな。
並列化に向いたアルゴリズムをつかわにゃ早くならんしな。
ていうか変数shareしすぎ。
405:デフォルトの名無しさん
10/07/03 08:13:40
だらだらと下手糞なコードを書いて速くならねえよと喚かれてもな
そんな記事にはほとんど価値がない
406:デフォルトの名無しさん
10/07/03 09:47:23
結局バグってたっぽいｗ
コメントが間違ってなければだが。
407:デフォルトの名無しさん
10/07/03 10:07:39
記事自体は、アルゴリズムによって効率的に並列化できるとは限らないから云々んという内容なので、
記事自体が（素人にとっては）無意味だとまでは言わんが、
この人偉そうな言い方したり他人の記事に対しては重箱レベルで突っ込んだりもしてるくせに
自分の記事は内容が結構いい加減なんだよな。
408:デフォルトの名無しさん
10/07/03 11:48:12
そんな人は世間にはいっぱいいる