- 1 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]
- マルチスレッドプログラミングについて語るスレ
■前スレ
マルチスレッドプログラミング相談室 その６
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
■過去スレ
その１ 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/
OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他突起する事項】
- 552 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 20:41:56 ]
- >>550
んだんだ、
それに、Cなんだから、void * が絡むときはキャストしない方が
素直で、読みやすいコードになる。
たとえば、
double *data = (double *) arg;
は、
double *data = arg;
としろ、ってことね。C++から来た人はこれをやりたがるのね。
C++だとこの場合にもキャストが必要だから。
乱文澄まそ
- 553 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 01:49:59 ]
- >>551
pthread_create(&a[i], NULL, (double *)thread_func, (double *)array);
は単に見落としていたようです。
お手数掛けて申し訳ないです。
直したらこの行のエラーは出なくなりました。
>>552
C++をやっていたわけではないのですが、配布されたソースコードの例にはこの形で書かれていたのでそれに準じて書きました。
そしてまだ14行目でエラーが出ますがpthread_selfの扱い方はそもそもこれでよいのでしょうか？
ちょろっと調べて出てきたものを使っただけなのでよく理解していません。
- 554 名前：553 mailto:sage [2009/04/21(火) 02:06:23 ]
- すみません、調べたらわかりました。
ただし他の問題が浮上しました。
pthread_t型をint型か何かに変換できないんですかね・・・。
- 555 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 02:31:33 ]
- >>554
pthread_tはポインタか構造体かなんかでしょ。
そもそも、別の型に代入しちゃいけない。
語のライブラリだと結構やろうと思えば別の型
に無理やり代入する事も出きるけどしちゃいけない、
内部に干渉しちゃいけないものがある。
大体識別値(discriptor)と呼ばれるものなんかがそう。
あと、初心者の内はメモリ操作が簡単にできる事が解って乱用する
人がいるがポインタのキャストはやたらめったらつかうもんじゃない。
てか、君の悩みはスレッド以前の問題だから、Cの初心者スレなんか
で質問しなさい。
- 556 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 20:37:55 ]
- 言い方は気にくわないなw
小さい芽潰して楽しんでるふうにしかみえねーよ老害
>>554
pthread_tはunsinged longのtypedefだよ
- 557 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 21:56:02 ]
- >>556
何を言ってるんだおまえは？ >>550のwarningを100回読み直してから出直してこい
- 558 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 00:05:38 ]
- ＞小さい芽潰して楽しんでるふうにしかみえねーよ老害
ふーん
芽をつぶして楽しんでて害なんだ
ふーん
- 559 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 01:49:54 ]
- そうなんじゃね、多分。
- 560 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 02:46:06 ]
- 大人なんだからもっと仲良くしろよ
- 561 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 21:38:45 ]
- 歯痛制御で俺の虫歯を何とかしてくれ
- 562 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 22:28:22 ]
- ﾁｭｲｰﾝ ｷﾞｷｨｨｰｰ
- 563 名前：555 mailto:sage [2009/04/22(水) 22:56:29 ]
- >>556
俺、21歳なんだが。3D関連でC++始めて5年以上にはなるが、
そうか俺も、もう老害か・・・。
- 564 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 00:01:02 ]
- >>561
本業歯医者の趣味グラマだけど何か用？
- 565 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 02:10:25 ]
- >>564
医者の趣味グラマっておおいな。
LHAも医者だし猫プロの筆者も医者。
しかも、本業より優秀そうなんだよな・・・。
- 566 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 02:33:52 ]
- 本当は工学系にいきたかったのに、
なまじっか頭いいと医療系への進学を勧められちゃう奴って多いからな
- 567 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 09:19:51 ]
- いつも思うんだけど、歯科治療技術も日々発展してるだろうから
古い医者より新しいところの方がいいのかねえ
- 568 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 11:19:32 ]
- ジャストシステムのスタートアップにも医学生がいたな。
人間って本当に不公平にできてるよ。
- 569 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 12:48:15 ]
- >>564
予約時間の十分前には歯科に着いているのに
待合室で一時間待たされ、診察室に通されたと思ったら
また三十分以上待たされるのを何とかしてくれ
どう見ても歯科医と歯科助手がデッドロックを起こしているようでなかなか回ってこない
- 570 名前：デフォルトの名無しさん [2009/04/23(木) 19:35:34 ]
- >>569
誰がうまいこと言えとｗ
デッドロックは言いえて妙だったわ。
- 571 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 23:58:32 ]
- >>567
少なくとも、レントゲン撮影したら「現像するから日を改めて」なんてところは止めた方がいい。
今時、治療椅子ごとに端末があってそこで見られるのが当たり前。
- 572 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 09:00:21 ]
- >>571
端末は無いけど、数分で現像したフィルムができるのが普通じゃない？
2,30年前からそうだったと思うんだけど
- 573 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 09:44:28 ]
- いい加減にしとけよ
- 574 名前：デフォルトの名無しさん [2009/04/24(金) 11:57:45 ]
- マルチスレッドと減増
関係あっても、遠い存在のような
- 575 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 17:51:20 ]
- >>556
老害ではなく、基地害だ
- 576 名前：デフォルトの名無しさん mailto:sage [2009/05/02(土) 22:30:20 ]
- 俺の日記帳
今日は5月2日です。
何してるの？
- 577 名前：デフォルトの名無しさん [2009/05/04(月) 23:25:22 ]
- C++0xではマルチスレッドプログラムを組むのは
容易になるのであろうか
- 578 名前：デフォルトの名無しさん mailto:sage [2009/05/04(月) 23:26:23 ]
- C++でマルチスレッドは危険ですよ
- 579 名前：デフォルトの名無しさん mailto:sage [2009/05/04(月) 23:36:49 ]
- >>578
Win32本では平気でマルチスレッド走らせる例が書いてあるけど
デッドロックについても詳しく説明してある
- 580 名前：デフォルトの名無しさん mailto:sage [2009/05/05(火) 04:20:22 ]
- >>579
なんだその会話になってないレスは
- 581 名前：デフォルトの名無しさん mailto:sage [2009/05/05(火) 06:50:37 ]
- CやC++の言語レベルではマルチスレッドについての取り決めはない。
ライブラリ(pthreadなど)やプラットフォーム(osやハードウェア)や実装(コンパイラ)レベルで、
扱いが決められているので、そういったものの前提抜きでマルチスレッドは語れない。
- 582 名前：デフォルトの名無しさん mailto:sage [2009/05/05(火) 09:33:35 ]
- メモリモデルの仮定が入っちゃうからやりにくいだろうなあ
- 583 名前：デフォルトの名無しさん mailto:sage [2009/05/05(火) 09:58:42 ]
- >577
concurrency 周りが大幅に強化されてるんで、恐らくは。
- 584 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 12:04:34 ]
- マルチスレッドにする利点は何？
複数の処理を同時に走らせることができるなんて妄想は無しで。
- 585 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 12:10:53 ]
- 世界の全てが妄想なので、答えは消滅しました。
- 586 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 12:12:54 ]
- 複数の処理を同時に走らせることができる、妄想で無しに。
- 587 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 13:11:27 ]
- 個人的には>>584が何故「複数の処理を同時に走らせることができる」ことが妄想だなんて妄想を抱いたのか知りたい希ガス。
マルチスレッドの利点は全てそこから派生しているはずなのだが。
- 588 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 13:25:02 ]
- >>587
TSSは同時ではないとでも言いたいんじゃないか？
- 589 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 15:05:51 ]
- >複数の処理を同時に走らせることができる
ってのはいわゆる手段なんで。
大元の目的は「暇をもてあましてるリソースを有効活用する」だな。
マルチスレッドはCPUがヒマしてる場合の、GPGPUはGPUがヒマしてる場合の手段だな。
>584がどんな妄想してるか迄はわからんが。
- 590 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 15:53:09 ]
- >>589
それ以外にもあるぞ。むしろプログラマ的にいちばんうれしいのは、コンテキストの異なる処理を明示的な切り替え無しに同居させられることじゃなかろうか。
重い処理を別スレッドでガリガリ処理しつつ、その進行状況をGUIで表示するとか。
- 591 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 23:10:29 ]
- ハァ？
すべてをファイル・デバイスにしてそれをpollすればシングルスレッドで可能ですが何か？
- 592 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 23:20:27 ]
- スレタイ無視
- 593 名前：デフォルトの名無しさん mailto:sage [2009/05/09(土) 23:39:00 ]
- 昔のunixはスレッドなしでもfork/execだけでたいていの事はやれてたな。
- 594 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 05:27:53 ]
- >>591
ちょっと話違うが、Androidのセンサーまわりの設計もそんな感じ。
だが、そのファイルディスクリプタをもらう元が、１つしかなかったり
してセンサーごとにドライバが作れない。
1.0のころはモジュール化すらされてなかったり、1.5になっても
いまだダセー設計だし。設計したやつの顔が見たいな。
- 595 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 08:32:10 ]
- ドライバといった低レベルI/O処理の基本はスレッドより割り込み。
割り込みがないディバイスだとポーリングも使うけど。
- 596 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 09:07:05 ]
- 何かの処理で待ちも含めてぐるぐる回りながら、他の処理も同時にやりたい、とかいう場合に
いちいち処理を細切れにしてpollを含むメインループから呼び出す形に縛られるのは面倒だわな。
マジレスすると。
- 597 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 10:29:43 ]
- >>593
でも今はマルチスレッドがサポートされているということは、その煩雑な方式では力不足だったってことだよね。
- 598 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 10:51:01 ]
- 今のところは、
やることを細切れにできるようにしておいて
pollするスレッド(大半の時間は待機)が
少数のワーカーに仕事を振り分け
ワーカーはひたすら仕事だけを待ちつづける、というやり方が
I/O待ちやマルチCPU(コア)を有効に生かせ、
メモリやコンテキストスイッチのロスも少なく出来ると言われてるな。
- 599 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 10:56:07 ]
- 開発効率という効率を無視すれば、それがベストだねw
- 600 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 13:17:08 ]
- OSのスケジューラをエミュレートしてるだけのような
- 601 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 15:04:43 ]
- コア数を大幅に越えるスレッドを生成すると、
コンテキストスイッチのせいでむしろ性能が低下する。ってのは本当なの？
実測して確かめたいんだけど、どういうコードを書けばいいのか解らん。
えろいひと教えて
- 602 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 15:07:34 ]
- スレッドプールにすりゃ解決よ
- 603 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 15:11:52 ]
- >>601
本当
スレッドに手を出した頃それに嵌ったことがある
各スレッドの同期にmutex/conditionを使う形で大量のスレッド作って試してみればわかるよ
むやみにスレッド数を多くするのはそもそも設計が良くないです
- 604 名前：デフォルトの名無しさん [2009/05/10(日) 16:01:38 ]
- オーバーヘッドが増大する。 スレッドの多さは関係無し。
たとえば1ms以内で終了するスレッドを生成すれば効率悪い。
- 605 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 16:02:56 ]
- >>601
スレッドって、一般にはコンテキストスイッチが入らない
（だから軽い）というモノだろう？
原理的には性能低下は無い。
但し、実際のところコア間でキャッシュを共有してたり、
メモリバスを共有してるので、複数のコアを同時に使うことで
シングルコアよりも性能低下することはありうる。
- 606 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 16:22:26 ]
- マルチスレッドのプログラム組んでるんでて
ある変数に複数のスレッドから同時にアクセスできるときは
排他的処理しないとだめ？
というか たぶん今のエラーはそうだろうと思う
- 607 名前：デフォルトの名無しさん [2009/05/10(日) 16:24:10 ]
- 複数スレッドからアクセスしても、OSがエラーはいたことはないな。
値は、ぶっ壊れるけどね。
- 608 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 16:28:00 ]
- 読むだけなら問題ない
- 609 名前：デフォルトの名無しさん [2009/05/10(日) 16:29:54 ]
- 読み書きしても、エラーでたことない。
たとえばグローバルsum=0に、複数スレッドから足し算してもエラーで停止しないが。
- 610 名前：デフォルトの名無しさん [2009/05/10(日) 16:31:49 ]
- どういった場合に、メモリーエラーが起こるのかが知りたい。
- 611 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 16:33:36 ]
- >>605
> スレッドって、一般にはコンテキストスイッチが入らない
今コンキストスイッチしないのって絶滅危惧種だろ
- 612 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 16:36:05 ]
- なるほど
変数がスタックで削除したり追加したりだからダメなのか
- 613 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 18:23:53 ]
- >>605
マテ、スレッドでもコンテキストスイッチは発生するぞ。
スレッドが(プロセスに比べて)軽いのは、スタックとレジスタだけ
切り替えれば済む(これもコンテキストの切り替えだ)からであって、
コンテキストスイッチそのものが行われないからじゃない。
- 614 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 18:26:42 ]
- １CPUの場合はタイムスライスだけになるから減らないが、
CPUが複数ならスイッチ自体を減らせるという話じゃないかい。
- 615 名前：デフォルトの名無しさん mailto:sage [2009/05/10(日) 22:05:51 ]
- >>613
ユーザランドでのスレッド実装だと
カーネルモードに入る回数が少なくて済むとかじゃね？
というかこの手のは、何が重いか時代により激しく違ってくるから
一般論といってもそれが何時のものかによるなあ
- 616 名前：デフォルトの名無しさん mailto:sage [2009/05/11(月) 21:55:27 ]
- 昔を語るのが一般とは思えない。
- 617 名前：601 mailto:sage [2009/05/11(月) 22:46:47 ]
- 時代によって変わるもんなのか。
レジスタ、スタックの退避とか、カーネルに入って出てくる処理とかが重いのかとかとか思ってたんだけど。
fiberは軽いよ。とか聞くけど、それはおいといて。
>>603
mutexとか排他は考えないで、純粋に「コンテキストスイッチ」処理がどれくらい重いもんなのか
図りたい。
linuxでpthread使ってやろうと思ってるんだけど、どんなコードを書けばいいんだろ
単純に0から0xffffffffまで足す処理をシングルスレッドでやるか、
0〜0xffを足す処理を0x1010101個のスレッド立てて計算させて、どっちが早いか。とか？＜そりゃないだろって
- 618 名前：デフォルトの名無しさん [2009/05/11(月) 22:57:13 ]
- >>617
CPUの数だけ分割するのが速い
- 619 名前：デフォルトの名無しさん mailto:sage [2009/05/11(月) 23:28:58 ]
- 例えば
20ms(OS次第)以上かかる計算処理を一つのJobとして
Job計10000個をキューに入れる。
スレッドをプールしておいて、各スレッドはキューからJobを取り出してひたすら実行する。
この時、プールするスレッド数をプロセッサ数と同数の場合と2000個の場合とで実行時間を計る。
現実的には、スタック領域以外にも
各スレッドで多少の独立したメモリ領域は使うことが多いと思われるので
ただの(レジスタやスタックで納まる)計算はではなく、
16Kなり64Kなりの領域をスレッド毎に確保しておいて
その内部の値を使った計算とする。
等というのはどうだろうか。
- 620 名前：デフォルトの名無しさん mailto:sage [2009/05/11(月) 23:39:02 ]
- 別にキューに入れる必要無いな。
同じことを繰り返すだけなんだから、CASを使ったカウントアップだけして
一定の数字になったらスレッド終了で充分か。
これなら、共有メモリを使えば、プロセスとの比較も出来る。
ただ、スレッドは「スタートのシグナル」を全部同時に出すことが出来るけど
プロセスだとどうなんだろ。全然知らない。
- 621 名前：デフォルトの名無しさん [2009/05/21(木) 21:54:47 ]
- 昔はPVM、今の時代はMPI
そしてOpenMPとMPIのハイブリッド実行が主流なのだろうか
- 622 名前：デフォルトの名無しさん mailto:sage [2009/05/21(木) 22:39:20 ]
- ＞同じことを繰り返すだけなんだから、CASを使ったカウントアップだけして
＞一定の数字になったらスレッド終了で充分か。
こんな非現実的な処理の時間を計測して何の意味があるわけ？
- 623 名前：デフォルトの名無しさん mailto:sage [2009/05/21(木) 22:40:10 ]
- おそらくプロセッサ（コア）が増えれば増えるほど遅くなると思うけど。
- 624 名前：デフォルトの名無しさん mailto:sage [2009/05/21(木) 22:44:10 ]
- ああ読み違えてたすまんのう
単に処理繰り返し数のカウントで使うだけってことね…
- 625 名前：デフォルトの名無しさん mailto:sage [2009/05/21(木) 23:23:37 ]
- VC(VisualStudio2005)でコーディングしております。
「g_hThread = (HANDLE)_beginthreadex(NULL,0,MainLoop,0,0,&g_dwThreadId)」
で、スレッドを生成し、そちらで、
if(GetAsyncKeyState(VK_UP)&0x8000)
ではキーが取得できるのに、
GetKeyboardState(diks)
if(diks[VK_UP] & 0x80)
ではキーが取得できません。
どうも、メッセージキューやらが原因みたいですが、理屈がイマイチわかりません。
解決策や問題点など、教えていただけると幸いです
- 626 名前：626 mailto:sage [2009/05/22(金) 00:14:01 ]
- 追記です。
そもそもGetKeyboardState()はメッセージキューに溜まったものを見るものであって、
新しく生成したスレッドでは、肝心のメッセージを取得することができない、、、
というあたりまではなんとなく理解できました
ちなみにやりたいことはキー情報の一括取得（できればリアルタイムの）です。
（GetAsyncKeyState()では１つ１つしか取れないので･･･
引き続き、解決策などありましたら、お願いします
- 627 名前：626 mailto:sage [2009/05/22(金) 01:06:46 ]
- 生成したスレッドの方で、
// Threadのインプットのアタッチ
int targetThread, selfThread;
targetThread = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
selfThread = GetCurrentThreadId();
AttachThreadInput(selfThread, targetThread, TRUE );
/*===== メインループ =====*/
// Threadを切り離す
AttachThreadInput(selfThread, targetThread, FALSE );
とすれば、GetKeyboardState()でも一応取得できました。
荒療治な気がしますが･･･
もっと良い方法などありましたら、お願いします
- 628 名前： ◆0uxK91AxII mailto:sage [2009/05/22(金) 02:41:05 ]
- >>617
適当なsystemcallを行い、前後でCPUのtimestampでも読めば、
最も軽い場合については、調べられる。
>>625
DirectInputを使うとか。
- 629 名前：デフォルトの名無しさん mailto:sage [2009/05/22(金) 03:20:02 ]
- >>627
GetKeyboardState()が使用する入力情報は、スレッドごとにある。
AttachThreadInput()はそれを共有させるためのAPIなので、その目的なら
それが一番適切な方法。
ただ、フォアグラウンドウインドウにAttachしてるのは間違いじゃないか？
GetAsyncKeyState()は自分のプロセスが非アクティブでもキー情報を取得できるAPI。
自プロセスの別スレッドでキー入力を拾う目的で使うのは、使えないことはないが
自分がアクティブかどうかの確認が必要で面倒。
- 630 名前：626 mailto:sage [2009/05/22(金) 04:59:32 ]
- >>628
DirectInputは同じような理由で取得できず...(・ω・
>>629
問題なく動いてるんで今の形(フォアグラウンド)で放置してたんですが、
ウインドウハンドルって引数以外で取得できるんでしょうか
- 631 名前：デフォルトの名無しさん mailto:sage [2009/05/22(金) 06:02:44 ]
- >>630
GetWindowThreadProcessIdもGetForegroundWindowもいらない。
beginthreadexを呼んだスレッドで、そのままAttachするだけ。
そもそも、自分のウインドウを取得するのにGetForegroundWindowを
使うこと自体おかしい。
アプリケーションを起動したら必ずフォアグラウンドになるわけではないし。
- 632 名前：626 mailto:sage [2009/05/22(金) 15:13:54 ]
- 確かにかなり回りくどいことしてました。
ただ、Attachの処理は生成処理の直下で一度だけ呼び出しても機能しなかったので、
beginthreadexを呼んだスレッドID(MainThreadId)だけをセーブして、
>>627と同じ場所で「AttachThreadInput(CurrentThreadId, MainThreadId, TRUE );」という形にまとめました。
- 633 名前：デフォルトの名無しさん mailto:sage [2009/05/22(金) 16:18:42 ]
- 新しく作成されたスレッドはGUI関連のAPIを呼び出すまでメッセージキュー等が
作成されないから、スレッド作成直後だと失敗するね。
新しいスレッドでウインドウを持っているならウインドウ作成後、ウインドウが
なければPeekMessageの空呼び出しの後でAttachがいいかな。
- 634 名前：??? [2009/05/22(金) 16:58:17 ]
- アセンブリ言語によるプログラミングで、１＋２＋３＋・・・・＋１０と、１から１０までの足し算をするプログラムはどのようなものになりますか？
１６進数表現です。
- 635 名前：デフォルトの名無しさん mailto:sage [2009/05/22(金) 17:14:22 ]
- まずは正しいスレッドを探すことからだな
- 636 名前：デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:56:35 ]
- 質問です。
constで定義されている、読み込み専用の変数に対して
複数のスレッドがアクセスするとき、同期（クリティカルセクションなど）は
必要ありますか？
- 637 名前：デフォルトの名無しさん mailto:sage [2009/06/10(水) 07:47:41 ]
- よっぽど変なハードウェアでない限り
要りません。
- 638 名前：デフォルトの名無しさん [2009/06/10(水) 19:52:05 ]
- volatileで十分ｗ
- 639 名前：デフォルトの名無しさん mailto:sage [2009/06/13(土) 18:02:44 ]
- volatile使うやつは情弱
- 640 名前：デフォルトの名無しさん mailto:sage [2009/06/26(金) 02:20:50 ]
- WindowsXP、VC2008EEの環境で作っています。
>>636の質問とかぶるのですが、１つのコンテナを複数のスレッドからイテレータでアクセス(読み込みのみで書き込みはない)しています。
実行時にイテレータを使った部分(直接使用しているのはSTL)でエラーが出て強制終了になってしまいます。
試しにスレッドを１つにしたらエラーは出ませんでした。
どういった原因が考えられるでしょうか？
- 641 名前：デフォルトの名無しさん mailto:sage [2009/06/26(金) 03:48:25 ]
- そのSTL実装がスレッドセーフじゃないんでしょ。
機能としての読み込みであっても、内部で書き込みしていて競合する場合もあるだろう。
アトミックなところまでスレッドセーフが保証できないならロックすべき。
- 642 名前：デフォルトの名無しさん mailto:sage [2009/06/26(金) 04:59:50 ]
- >>641
なるほど・・。
マルチスレッドは難しいですね。
- 643 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 11:06:03 ]
- >>640
単純に興味本位なんだが、const_iterator でも駄目なの?
- 644 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 11:09:45 ]
- 最近マルチスレッド環境下でスレッド毎にプールを持つ
malloc() 実装がよくあるよね? 諸々の事情でそれが使
えない場合、アプリ側で出来る事ってある?
OO 的に小さなオブジェクトを生成／破棄するんだけど、
スレッドを跨って破棄を委譲するケースもあるんだ。で
も、単純にメモリ管理スレッド作っても過去の効率の悪
い malloc() 実装の焼き直しみたいになって多分効率悪
いと思うんだよね…。
- 645 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 11:16:05 ]
- アプリ側でそういう実装をやってるのはあっても動作環境側でそんな実装やってるの在るか？
複数のプール持つ実装はあるだろうけどスレッド固有になるような実装してたらそれこそスレッド跨げないし
- 646 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 11:49:37 ]
- >>645
ああ、中央ヒープはあるんだよ。でも、スレッド毎にも
管理されるよね? 多分細かくスレッドが生成／破棄され
るようなケースではかなり改善されるんだと思う。
goog-perftools.sourceforge.net/doc/tcmalloc.html
↑Google の tcmalloc はコアヒープとスレッド毎のキャッ
シュという形で実装されている。
people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
↑FreeBSd の jemalloc もスレッド毎に管理されてるみ
たい(TLS)だけど、要求されるサイズによって割り当て
部を買えるような話がある。
でも、やっぱりスレッド跨ると古い malloc() と同じ話?
うーん、ここまで来ると「どのコアで動くか」まで関連
するかなぁ…。
- 647 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 12:19:54 ]
- jemallocは自分が割り当てられたarenaをヒープのメタデータにつっこんでおいてfree時にはそこから解放するようになってる
割り当てはそれこそぽんぽん次のarenaをTLDに結ぶけどさ
そうでもしなきゃFreeBSDのデフォルトになれてない
完全に一切ロックせずスレッド固有のヒープにするなんてのはアプリ内の実装でなきゃ出来んよ
- 648 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 12:35:06 ]
- いやだからそのアプロ側でどうすんの? ってのを聞いてるわけで…。
- 649 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 12:43:37 ]
- 一体何を心配して居るんだお前は？
- 650 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 13:46:18 ]
- 小さいメモリ大量なら、固定長のバッファをリンクリストかなんかに
つないでおいて、利用すればいいじゃん。malloc, freeよか速い
だろ。
- 651 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 17:04:33 ]
- >>644
mallocにしてはやりすぎじゃない？
C++のallocatorならそういうのもあると思う。
- 652 名前：デフォルトの名無しさん mailto:sage [2009/07/06(月) 15:13:06 ]
- とりあえず何も考えず素直に作って問題が出たら詳細に
考えることにするよ。一応アロケータ的なインタフェイ
ス挟んでるから後からでもなんとかなると思う。
malloc/free に時間かかってる／かかってないの判定と
かは gprof 辺りで大丈夫なんだっけ?
|
 |
