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

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・言語・環境は問わないが、それゆえ明記すべし。 テンプレ 【ＯＳ】 【言語】 【実行環境】 【その他突起する事項】 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 辺りで大丈夫なんだっけ? 653 名前：デフォルトの名無しさん mailto:sage [2009/07/07(火) 13:30:13 ] >>652 一応gprofでも判らなくもないと思う。呼び出し回数は記録されないけどね。 使える環境なら、vtuneみたいなツールを使う方が(当然)判りやすい。 654 名前：デフォルトの名無しさん mailto:sega [2009/08/04(火) 10:34:44 ] pthreadで、デタッチ状態のスレッドをポコポコつくったりしてるとき 生成したスレッドのうち今何個生きているかを知りたいんだけど pthread_hogehoge() で何か知れるような手段用意されてたっけ？ 655 名前：デフォルトの名無しさん [2009/08/04(火) 11:52:30 ] マルスレage 656 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 12:00:52 ] 無いんじゃない？atomicなカウンタでも使えばいいじゃん。 657 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:07:08 ] >>656 もしそういうカウンタがもうあるなら再車輪せずに済むかな、と。 658 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 18:51:12 ] Linuxの話だけど、この件については他でも同じ ttp://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html A thread does not maintain a list of created threads, nor does it know the thread that created it. スレッド数だけであれば、psでスレッドの情報出すときと同じ方法でできる? 659 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 21:20:30 ] >>658 pstreeとかのソース読んだからまあ大体のことはできるんだけど そうか、管理しないことをウリにしてんのか。仕方ないなぁ。 スレッド管理はOS任せか〜。そりゃそうだよなぁ。 660 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 15:09:11 ] Javaで複数のインスタンスのAというメソッドに同期をかけたい場合は、 どうすればよいのでしょうか？ 661 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 15:52:00 ] >>660 同期は(メソッドにかけるものじゃなくて)メソッドが アクセスするリソース(メモリやディスク)にかけるものだよ。 あと「同期」はスレッド間でイベントの発生待ち＆発生通知を 実現する場合に使われる単語。もしもスレッド間で (メソッドを通した)リソースへのアクセスの競合を避けるのが 目的なら、「排他制御(あるいはロック)」という単語を使うのが適切。 で、質問が(後者の)排他制御を実現する場合に関するもとすれば、 各インスタンスのメソッドAで(アクセスしたいリソースへの) 排他制御を実装するコードを単純に書けばいい、というのがレスになる。 もしも各インスタンスのクラスが同一ではないため、複数クラスで メソッドのコードを変更するのはプログラム構造が複雑になると 考えているなら、たとえば以下のようなヒントが参考になるかもしれない。 ・コールバック機構を利用して並行処理時に発生するバグを防止する 　　japan.internet.com/developer/20050927/25.html 662 名前：デフォルトの名無しさん mailto:sage [2009/08/09(日) 16:02:51 ] >>661 ご回答ありがとうございます。 プロセス起動時の初期処理用メソッド（DBからマスタを取得し、キャッシュする）に同期をかけたいと思っていました。 お返事どおり、メソッドではなく、リソース（オブジェクト）に対して、ロックをかけるのが正しいですね。 キャッシュクラスをシングルトンで実装し、同期化をさせることにします。 663 名前：デフォルトの名無しさん [2009/08/11(火) 00:33:30 ] メソッドにsynchronizedを付けると、同一インスタンスで１つのスレッドしか実行できないということですか？ 複数インスタンスあれば、実行できてしまうのでしょうか？ 664 名前：デフォルトの名無しさん mailto:sage [2009/08/11(火) 00:50:50 ] できてしまいます 665 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 22:09:06 ] staticメソッドなら大丈夫。 synchronized(Hoge.class) とか 666 名前：デフォルトの名無しさん mailto:sage [2009/08/12(水) 22:56:58 ] >>665 > staticメソッドなら大丈夫。 > synchronized(Hoge.class) とか そこまで書くならstaticメソッドじゃなくてもいいじゃん 667 名前：デフォルトの名無しさん [2009/08/16(日) 00:34:07 ] マルチスレッド環境でマスタデータをDBからとってきて、HashMapかListなどに持たせるのは 問題ないのでしょうか？ 基本的にJavaプロセスを起動している間にマスタデータが変更されることはない環境です。 668 名前：デフォルトの名無しさん [2009/08/16(日) 00:34:56 ] 667です。 データを持たせるHashMapかListはクラス変数で持たせたいのですが。 669 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 00:37:29 ] 情報不足 どういう問題がありえると思ってるんだ？ 670 名前：デフォルトの名無しさん [2009/08/16(日) 01:02:48 ] すみません。 HashMapとかListに数千件というマスタ情報を持たせるのがおかしくないのかという点と、 HashMapやListにデータを追加するときはロックをかけますが、データを取得するときは ロックをかけなくても問題ないかを知りたいです。 671 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 01:16:29 ] >>670 ハッシュなんてもんはメモリが許すなら数万件程度は入る事を前提で作るんだが 672 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 01:37:04 ] >>670 (すでに別の方法で同期済み等で) 追加と取得が同時には起きないと判っているなら、取得同士の間のロックは不要 追加と取得が同時に起きるかもしれないなら、取得にもロックは必要 673 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 06:35:50 ] 通信とかどうでもいいから普通にマルチコアに特化したライブラリってないのさ？ 674 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 08:59:53 ] つintel TBB 675 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 09:49:44 ] >>673 スレッド間通信が無くても役に立つマルチスレッドアプリとは何者？ 676 名前：デフォルトの名無しさん mailto:sage [2009/08/16(日) 21:13:28 ] ブルートフォースとか 677 名前：デフォルトの名無しさん mailto:sage [2009/08/17(月) 10:00:56 ] >>675 サーバとか

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef