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

マルチスレッドプログ ..

237:デフォルトの名無しさん
09/12/23 13:31:19
>>232
そんな事は起きないようにハードウェアが作られてる
物理的なメモリへのアクセス経路は1個しかないから、同じアドレスに同時にアクセス
なんて事は出来ない

命令が書いた順に実行されるかとか、他のコアやスレッド云々は >>235 の通り

238:デフォルトの名無しさん
09/12/23 13:31:47
クリティカルセクションを用いって書いてあるから、なんとなくWindowsかと思ってた。

239:デフォルトの名無しさん
09/12/23 13:32:15
>>235
ここはム板だから低水準の話はついていけないと思う

240:デフォルトの名無しさん
09/12/23 13:49:38
>>237
> 物理的なメモリへのアクセス経路は1個しかないから、同じアドレスに同時にアクセス
> なんて事は出来ない

いつの時代の人?

241:デフォルトの名無しさん
09/12/23 14:00:02
>>239
いやそれは無い

242:デフォルトの名無しさん
09/12/23 14:00:28
ん？今はどこが違うの？

243:デフォルトの名無しさん
09/12/23 14:04:04
>>235
x86は巨視的には古典的設計だからまだ理解しやすいけど、PPCなんかだとリオーダー
とかが剥き出しになってくるからさらにごちゃごちゃするんだよな

244:デフォルトの名無しさん
09/12/23 14:06:45
そこでeioioですよ！

245:デフォルトの名無しさん
09/12/23 14:07:20
間違えた、eieioだった
イーアイイーアイオー！

246:デフォルトの名無しさん
09/12/23 14:28:55
ｴｲｯｴｲｯｵｯｰ

247:デフォルトの名無しさん
09/12/26 12:32:01
この辺の話題が体系的に書かれてる教科書が欲しい

248:デフォルトの名無しさん
09/12/26 14:41:39
開拓が進行中のジャンルだから、書いたそばから陳腐化しそうでなかなか難しいかも
しれないな

249:デフォルトの名無しさん
09/12/31 15:09:39
何をもって高性能とするかをはっきりさせたいな
シングルコア100%アイドル3コアでできることを4コア25%ずつで処理することに意味はあるの？

250:デフォルトの名無しさん
09/12/31 15:12:36
>>249
に追記
並列処理の有利はわかるけど、これからは直列処理も並列化しようとしてるんでしょ
そんなの意味ないよねという話

251:デフォルトの名無しさん
09/12/31 15:50:00
1コア100%3コア0%ってCPUがボトルネックになってんじゃねーの

252:デフォルトの名無しさん
09/12/31 15:50:26
何を言ってるの？

253:デフォルトの名無しさん
09/12/31 21:19:08
>>249は軽くエスパーが日本語に翻訳しないと分かりづらい

4スレッドにしたら全部25%になっちゃうような処理までマルチスレッドにする
意味あんの、って言いたいんだろうし、だからCPU屋は2コアや4コアで現状維持
しながら別の進化の方向性を探ってるのも事実
だがそもそも、そういう微妙なケースにまで頑張って適用しようぜMTマンセー、
というようなスレではないので、そんな的外れなこと言われても一瞬何の話だか
分からんし、今更何をとしか言いようがない

254:デフォルトの名無しさん
09/12/31 21:28:43
>>253
日本語でおk

255:デフォルトの名無しさん
09/12/31 21:35:30
>>253
余ってるCPUに仕事振る余地のない処理なら
それでいいんじゃね？

256:デフォルトの名無しさん
09/12/31 21:39:14
>>249の問題提起自体が微妙
アムダールの法則くらいで十分じゃねーの？

257:デフォルトの名無しさん
10/01/03 18:49:32
そもそも並列化できない処理まで並列化しようとしてるなんて話は聞いたこともない。
誰が言ったんだそんなこと。

258:デフォルトの名無しさん
10/01/03 21:49:55
>>249が言ってるな

259:デフォルトの名無しさん
10/01/16 03:00:47
質問させてください。
【ＯＳ】　UNIX/LINUX
【言語】　C言語
【実行環境】　gcc
【その他特記する事項】
メインスレッドからn個のスレッドを作成->全ての終了を待つという場合、
int i;
pthread_t id[n];
void* res[n];
for (i=0; i<n; i++) 　pthread_create(&id[i], NULL, funcptr, arg);
for (i=0; i<n; i++) 　pthread_join(id[i], &res[i]);
こんな感じで大丈夫でしょうか？
それとWindowsにあるWaitFor～みたいに複数待つというのは無いのでしょうか？

260:デフォルトの名無しさん
10/01/16 03:18:30
>>259
>WindowsにあるWaitFor～みたいに複数待つ

つ URLﾘﾝｸ(developers.sun.com)

261:デフォルトの名無しさん
10/01/26 00:12:16
スレッドを終了させないままアプリを閉じた場合
やっぱメモリリークとか起きるの？

262:デフォルトの名無しさん
10/01/26 00:20:29
環境を想定しないとなんともいえない。

263:デフォルトの名無しさん
10/01/26 00:33:22
>>261
OS破壊されるぞ？いいのかそんなことしても

264:デフォルトの名無しさん
10/01/26 00:49:27
>>261
ja.wikipedia.org/wiki/メモリリーク

265:デフォルトの名無しさん
10/01/26 10:22:10
破壊されるようなOSなんか使うなw

266:デフォルトの名無しさん
10/01/26 16:03:33
MTでそんな脆いOSはちょっと想像付かないなｗ
携帯の奴とかはどうなんだろう

267:デフォルトの名無しさん
10/01/26 16:15:09
問題(1) 名前を入れる入力ダイアログ１つとボタンを1つ表示し，ボタンを押したときは時間に応じて，
　05時～11時　「おはようございます，○○さん」
　11時～17時　「こんにちは，○○さん」
　17時～05時　「こんばんは，○○さん」
と表示するJavaScriptプログラムを作成しなさい。

268:デフォルトの名無しさん
10/01/26 16:20:40
断る。

269:デフォルトの名無しさん
10/01/26 16:24:21
キミの実力を見せてみろ

270:デフォルトの名無しさん
10/01/26 16:28:23
マルチスレッドと何の関係が

271:デフォルトの名無しさん
10/01/26 16:32:31
スレ違いでした。
すいません・・

272:デフォルトの名無しさん
10/01/26 17:10:35
VCでマルチスレッドアプリをトレース実行してるとかなりの頻度でOSごと固まるんですが、
マルチスレッドの場合のデバッグはデバッガ使わないのが普通なんですか？

273:デフォルトの名無しさん
10/01/26 17:48:30
PCが貧弱

274:デフォルトの名無しさん
10/01/26 18:05:06
嫁が貧乳

275:デフォルトの名無しさん
10/01/26 18:13:39
ユーザが頻尿

276:デフォルトの名無しさん
10/01/26 18:19:25
>>272
詳細なテキストサービスをオフにすると少し幸せになれるかも。
ATOK使いの俺には無縁な話。

277:デフォルトの名無しさん
10/02/02 23:21:31
最近スレッド使い始めました。
クリティカルセクションとかインターロックで変数を共有するのは
なんとなく分かりました。
例えばCRITICAL_SECTIONを使う場合、アプリケーションで一つ用意すれば
よいのでしょうか?
極端に言えばCRITICAL_SECTIONをグローバル変数として定義して、
EnterCriticalSection等を使えばよろしいのでしょうか?

278:デフォルトの名無しさん
10/02/02 23:33:23
トイレに例えるなら何個個室があっても鍵がすべて連動してトイレにはひとりしか入れないってことだぞ
それでいいのか？

279:デフォルトの名無しさん
10/02/02 23:44:28
それでも良いが性能は良くない
性能向上のためにスレッドを使っているわけではないのなら、別に構わない
無理にシングルスレッドで処理するよりマルチスレッドの方が可読性が高くなることもあるからな
性能を上げたいのなら一人がどこかでロックを握ってる間全員が待たされるような構造は良くない

280:277
10/02/03 00:18:41
なるほど。問題点の指摘ありがとうございます。
では、3つスレッドがあるとして、1つは無関係で2つのスレッドで
変数を共有する場合は、クリティカルセクションをどう使えば
よろしいのでしょうか?
各スレッドループ中にCRITICAL_SECTIONを定義してりようすればよろしいのでしょうか?
何か根本的に勘違いしている気がしている気がします。

281:デフォルトの名無しさん
10/02/03 00:32:42
共有する変数がグローバルで1個しかないのならクリティカルセクションもグローバルで1個でいいよ

282:277
10/02/03 00:50:34
現在は全体からアクセスできる変数が一つです。
一気にやろうとはしないで少しずつ複雑なパターンを試してみます。
あと環境はWindowsです。失礼しました。

283:デフォルトの名無しさん
10/02/03 01:35:14
まあロックが1つで済むならデッドロックとか考えなくて済むし
可能ならその方が悩まない。
パフォーマンスの問題は、占有期間次第とも言えるから。

284:デフォルトの名無しさん
10/02/03 02:19:04
クリティカルな部分一個をトイレの個室一つと考える

285:デフォルトの名無しさん
10/02/03 04:12:03
たまに鍵かけないやつがいてトラブるんだ

286:デフォルトの名無しさん
10/02/03 07:23:37
そうするとトイレの中に
トイレがあって、その中にまたトイレがないと
説明不可能だろ。

トイレはネストできねーだろ

287:デフォルトの名無しさん
10/02/03 09:11:21
そうかクリティカルセクションはネスト出来たか

288:デフォルトの名無しさん
10/02/03 11:33:20
じゃあトイレがバスルームにあるということで

289:デフォルトの名無しさん
10/02/03 11:42:57
階層数に制限があるからダメ。

290:デフォルトの名無しさん
10/02/03 11:52:56
トイレ中に地震がくるのと
小便中に大便を催すのと
どっちが我慢できる？

291:デフォルトの名無しさん
10/02/03 13:45:14
メモリバリアとmutexの関係が解りません。
メモリバリアとmutexがどういうものか。とかじゃなくて、
関係性とか、必要とされる場面について解説してあるサイトないですか？

292:デフォルトの名無しさん
10/02/03 13:59:08
メモリバリア
Wikipedia項目ﾘﾝｸ

メモリバリアは単に自CPUのメモリアクセスの順序を制御するだけのもので、
mutexのようなスレッド間の排他制御 (後続のスレッドを進入させずに待たせるような) 機能は無い
メモリバリアはCPUの1命令に過ぎず、mutexはOSのスレッド管理と絡むもっと複雑なものだ
mutexを実装するOSの中の人は、複数のCPU間の連携のためにメモリバリアを使うかもしれない

293:デフォルトの名無しさん
10/02/03 16:33:38
メモリバリアかアトミック命令が無いとMutexは実装出来ない

294:デフォルトの名無しさん
10/02/03 20:55:32
>>291　は同期処理のバリアのことじゃないの？
Wikipedia項目ﾘﾝｸ

ロードストアのオーダリングの話と　mutex　はちょっと離れてる気がする

295:デフォルトの名無しさん
10/02/04 17:45:59
>>286
クリティカルセクションのネストって必要かな？

296:デフォルトの名無しさん
10/02/04 17:49:29
クラスのスレッドセーフなメソッドから同クラスのスレッドセーフなメソッドを呼び出す場合とかにあると便利かも

そういう動作を意図しなかった場合にバグらないっていう利点もあるね

297:デフォルトの名無しさん
10/02/04 17:55:39
同クラスなら同期処理しないプライベートメソッドを呼び出すのではないか

298:デフォルトの名無しさん
10/02/04 19:04:48
たとえば口座aから口座bに振替をおこなうには、
口座aと口座b両方のロックを取る必要がある、
という典型的な例は？

299:デフォルトの名無しさん
10/02/05 08:24:35
それは二つのCSをロックするだけでネストじゃないんでね？

300:デフォルトの名無しさん
10/02/05 09:08:04
こんな話題とメモリバリアの話題が同時進行するってかなりカオスな気がする

301:デフォルトの名無しさん
10/02/05 13:10:17
>>298
同時に入ってる必要は無くね？

302:デフォルトの名無しさん
10/02/05 21:40:05

両方とも、a→bの流れならトランザクションだけでよくないか？

303:デフォルトの名無しさん
10/02/06 00:40:47
スレッドがA、B、C、Dの4つあって
かならずA、B、C、Dの順番で仕事が
終わるようにするには

どんなアルゴリズム使えばいいのですか？

304:デフォルトの名無しさん
10/02/06 00:46:46
スレッド化する意味あるのか？
B,C,Dは寝かせておいて、Aが自分の仕事を終えたときにBを起こせばいいんじゃないか

305:デフォルトの名無しさん
10/02/06 13:44:25
スレッドの終了処理を順番にやる必要があるってことかな。
終わるタイミングを調整したいだけなら、
BがAの終了を待つ
CがBの終了を待つ
DがCの終了を待つ
って感じにやれば順番に終われるんじゃね?

306:デフォルトの名無しさん
10/02/06 18:28:33
そしてAがDの終了を待てば完璧

307:デフォルトの名無しさん
10/02/06 19:34:45
>>306
どうやって全部待てばいいの？

308:デフォルトの名無しさん
10/02/06 20:36:58
Eに管理してもらう

309:デフォルトの名無しさん
10/02/06 20:51:33
どうやるのか全然わからない

たすけて

310:デフォルトの名無しさん
10/02/06 22:14:37
Aの処理終了の際に2個のスレッドで破れるBarrier1を待つ
Bの処理開始の際に2個のスレッドに破れるBarrier1を待つ
Bの処理終了の際に2個のスレッドに破れるBarrier2を待つ
Cの処理開始の際に2個のスレッドに破れるBarrier2を待つ
Cの処理終了の際に2個のスレッドに破れるBarrier3を待つ
Dの処理開始の際に2個のスレッドに破れるBarrier3を待つ

311:デフォルトの名無しさん
10/02/06 22:16:11
>>310
>スレッドで破れるBarrier
こんなことすると破綻すると思うのですが
それは何か新しい概念なのでしょうか？

312:デフォルトの名無しさん
10/02/06 22:46:53
>>311
>>294のバリアのことだよ。
2個のスレッドがバリアに到達した瞬間にバリアが破れて同時に進行を再開する。

Wikipediaより…
並列コンピューティングにおけるバリア（英: Barrier）とは、同期方法の一つであり、
ソースコード中でスレッドやプロセスがある箇所で停止し、
他の全てのスレッドプロセスがバリアに到達するまで進行しないようなものを示す。

313:デフォルトの名無しさん
10/02/07 00:29:35
>>310
わかりにくい表現だな。

314:デフォルトの名無しさん
10/02/07 21:28:39
同期なり待機って言った方がわかりやすいな

315:デフォルトの名無しさん
10/02/11 00:13:07
追加削除順序を保持しつつ
効率的にアクセス可能なデータ構造って何があるの？

316:デフォルトの名無しさん
10/02/11 00:25:04
二分木

317:デフォルトの名無しさん
10/02/11 00:32:33
>>316
マルチスレッドの2分木のサンプル
教えて

318:デフォルトの名無しさん
10/02/11 00:50:06
>>315
Skip list.
実装例は java.util.concurrent.ConcurrentSkipListSet とかかな。

319:デフォルトの名無しさん
10/02/20 11:14:34
C++のマルチスレッドの本って
どんなのがありますか？

Intelの本は使い方しか書いてないで
困ってる

320:デフォルトの名無しさん
10/02/20 12:39:32
正直、使い方だけしか提示しようがない気がする
どこもかしこも開拓中で、定番というものが無い

321:デフォルトの名無しさん
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みたいだね
Wikipedia項目ﾘﾝｸ

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
そんな人は世間にはいっぱいいる