[過去ﾛｸﾞ] マルチスレッドプログラミング相談室 (986ﾚｽ)

マルチスレッドプログラミング相談室 http://toro.5ch.net/test/read.cgi/tech/997345868/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

728: デフォルトの名無しさん [sage] 02/10/31 11:06 APIで上げたスレッドからは一切Cygwinの機能を使わなければ なんとかなりそうだ http://toro.5ch.net/test/read.cgi/tech/997345868/728

729: デフォルトの名無しさん [] 02/10/31 17:33 pthread仕事で使ってる人います？ http://toro.5ch.net/test/read.cgi/tech/997345868/729

730: デフォルトの名無しさん [sage] 02/10/31 17:39 使うかもしれないから調査中 http://toro.5ch.net/test/read.cgi/tech/997345868/730

731: デフォルトの名無しさん [sage] 02/10/31 20:31 Cygwinのsocketは、未だthread safeではなさげ(DLLのソース読んで確認) ひとつのfdに対して複数スレッドでaccept(2)して、ひどいめに遭った http://toro.5ch.net/test/read.cgi/tech/997345868/731

732: デフォルトの名無しさん [sage] 02/11/01 02:38 cygwinってfork使えますか？ http://toro.5ch.net/test/read.cgi/tech/997345868/732

733: デフォルトの名無しさん [sage] 02/11/01 02:50 fork遅いよ っていうかスレ違いだろ http://toro.5ch.net/test/read.cgi/tech/997345868/733

734: デフォルトの名無しさん [sage] 02/11/01 10:45 cygwinってspoon使えますか？ http://toro.5ch.net/test/read.cgi/tech/997345868/734

735: デフォルトの名無しさん [sage] 02/11/02 11:49 >>734 knifeなら使えます http://toro.5ch.net/test/read.cgi/tech/997345868/735

736: デフォルトの名無しさん [] 02/11/12 19:32 Windowsであるクラスに参照カウントを持たせ、InterlockedIncrement./InterlockedDecrementで マルチスレッド対応にしようとしたのだが… void ref() { 　InterlockedIncrement(&m_ref);　 } void release() { 　if (InterlockedDecrement(&m_ref) == 0) { 　　delete this; 　} } ところが、delete thisの直後にref()が呼ばれると、m_ref自体が解放された領域にあるため、 とんでもない値になってしまう。参照カウントをメンバー変数にするのが間違い? どうしたらいんだろう？マルチスレッドのエキスパート様の降臨おながいします http://toro.5ch.net/test/read.cgi/tech/997345868/736

737: デフォルトの名無しさん [sage] 02/11/12 19:55 > delete thisの直後にref()が呼ばれる delete thisされたってことは、そのオブジェクトはもう参照されていない と判断されたんだがら、その後にrefが呼ばれること自体がおかしい。 http://toro.5ch.net/test/read.cgi/tech/997345868/737

738: デフォルトの名無しさん [sage] 02/11/12 20:25 参照カウントを0から始めたに100スレッド http://toro.5ch.net/test/read.cgi/tech/997345868/738

739: 736 [] 02/11/12 21:18 ある時点で、m_ref>0だったとします。 2つのスレッドが、それぞれ同時にref()とrelease()を呼び出すと… http://toro.5ch.net/test/read.cgi/tech/997345868/739

740: デフォルトの名無しさん [sage] 02/11/12 21:24 ref() と release() が互いに排他してなきゃ動くわけないじゃん。 http://toro.5ch.net/test/read.cgi/tech/997345868/740

741: 736 [] 02/11/12 21:35 void ref() { EnterCriticalSection(&m_cs); 　InterlockedIncrement(&m_ref);　 LeaveCriticalSection(&m_cs); } void release() { EnterCriticalSection(&m_cs); 　if (InterlockedDecrement(&m_ref) == 0) { 　　delete this; 　} LeaveCriticalSection(&m_cs); } としても、ref()でInterlockedIncrement()にたどり着いたときには… http://toro.5ch.net/test/read.cgi/tech/997345868/741

742: デフォルトの名無しさん [sage] 02/11/12 21:57 あるオブジェクトに触れるスレッドが一つふえたら そのオブジェクトの参照カウントをageておく必要があることに 気づいてないに1000はらたいら http://toro.5ch.net/test/read.cgi/tech/997345868/742

743: デフォルトの名無しさん [ sage ] 02/11/12 21:58 ＞739 それもなんだかおかしな動作だな。 refを発行する、というのは、どっかからobjectを貰ってきてるわけだろ。 で、releaseを発行するということは、所有権の一端を持っているわけだよな。 それで、deleteが実行されるというのは、 「refcount == 0かもしれないobjectが渡ってきた」 「release発行しすぎ」 ってなわけだろ。refするタイミングとか、考え直した方がいいんでないか？ http://toro.5ch.net/test/read.cgi/tech/997345868/743

744: 736 [] 02/11/12 22:36 refが参照カウントを増やす(objectを貰って来る)ためのものなのだが… http://toro.5ch.net/test/read.cgi/tech/997345868/744

745: デフォルトの名無しさん [sage] 02/11/12 22:52 736はひょっとしてCOMを知らない？ http://toro.5ch.net/test/read.cgi/tech/997345868/745

746: 736 [] 02/11/13 10:05 いやCOMじゃなくて。 あるオブジェクトのインスタンスが作られるとm_ref=1となっていて、 そのオブジェクトを例えば別のスレッドが使うためにコピーを作るとm_ref=2 となる。 まさにその瞬間に、インスタンスの元のホルダーがオブジェクトを破棄しようとすると、 m_refのインクリメントとデクリメントが同時に起きる。 Interlocked...は同時じゃないが、ref()とrelease()が同時に呼ばれrelease()を 実行しているスレッドの方が早くCriticalSectionを獲得して解放したのち、 InterlockedIncrementが呼ばれると、解放されてしまうので値が不定になってしまう。 http://toro.5ch.net/test/read.cgi/tech/997345868/746

747: デフォルトの名無しさん [sage] 02/11/13 10:35 「別のスレッドが使うためにコピーを作る」ときに 「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。 「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。 http://toro.5ch.net/test/read.cgi/tech/997345868/747

748: デフォルトは上限無しさん [sage] 02/11/13 10:42 >>746 Deleteされてしまうことがあるobject自身に、 objectの管理を「全て」任せようということ自体が無理。 Handler patternで行くか、refererにべたにcodeを書いてしまう。 http://toro.5ch.net/test/read.cgi/tech/997345868/748

749: デフォルトの名無しさん [ sage ] 02/11/13 10:44 つーかな。それはrefcountの問題と違うねん。たとえば、 method1() {delete str; str=0; } method2() {func( *str );} このメソッド２つが同時実行されるようなのとおなじ問題なわけよ。 あえて解決策を示すなら、 method1() {lock(); delete str; str = 0; unlcok(); } method2() {lock() if( str ) func(str) unlock(); } とかしないといけない。 http://toro.5ch.net/test/read.cgi/tech/997345868/749

750: デフォルトの名無しさん [sage] 02/11/13 11:21 ひょっとしてrefcountをさらにポインタや参照で管理しようとしてないか? そんなのrefcountの意味が全くないぞ。根本的にrefcountについて誤解してるだろ。 http://toro.5ch.net/test/read.cgi/tech/997345868/750

751: デフォルトの名無しさん [sage] 02/11/13 11:28 >>750 俺もそんな気がして来た。グローバルなオブジェクトや静的なオブジェクトを 参照カウントでやろうとしてるような気もするし。 http://toro.5ch.net/test/read.cgi/tech/997345868/751

752: 736 [] 02/11/13 12:37 >746 やっぱり、そういう事になりますか。 >749 それは、ちっとも解決にならない。 method2がこの場合ref()なわけで、ref()から戻ったら、そのオブジェクト使おうと するんだから。 >750 参照カウントは、扱われるインスタンス内に有りますが、 そのインスタンスを指すスマートポインターのようなクラスで持たなきゃならないって 事ですか? そうでなくて、インスタンスと別にアロケートして参照カウント作ってもだめって事だけ? >グローバルなオブジェクトや静的なオブジェクトを参照カウントでやろうとしてるような気もするし。 流石に、そんなこたぁない。 http://toro.5ch.net/test/read.cgi/tech/997345868/752

753: デフォルトの名無しさん [ sage ] 02/11/13 15:40 分からんヤツやな、、、 refする前にreleaseが発行されてrefcount==0になる 可能性があるなら、refする前に、oobjectが生きてて、 refできるか確かめないかんやろ。その結果、objectが 死んでるなら、refしてobject渡すのは諦めなアカン。 　で、そこでobjectが死んでるのが間違いなら、releaseか refの発行の仕方がオカシイんや。 http://toro.5ch.net/test/read.cgi/tech/997345868/753

754: デフォルトの名無しさん [sage] 02/11/13 16:49 >>752 > >746 > やっぱり、そういう事になりますか。 ｼﾞｻｸｼﾞｴｰﾝ? http://toro.5ch.net/test/read.cgi/tech/997345868/754

755: デフォルトの名無しさん [sage] 02/11/13 17:03 >>752 > 参照カウントは、扱われるインスタンス内に有りますが、 > そのインスタンスを指すスマートポインターのようなクラスで持たなきゃならないって > 事ですか? > そうでなくて、インスタンスと別にアロケートして参照カウント作ってもだめって事だけ? 場所は関係ない。ただし、インスタンスとカウンタの対応を管理することを考 えれば、インスタンス内に置くか「スマートポインターのようなクラス」って のが確実で手軽だし常套手段。 参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかっ てる? これは本来アトミックな処理なので、別スレッドに渡すってのも参照を 増やすことになるんだけど、それとカウンタの更新を別スレッドに分けちゃい けない。 単一スレッド内でコピーする場合は複製によるカウント処理が終るより前にオ リジナルが解放することはないので保護されるけれど、別スレッドにしてしまっ たらその順序が保証されなくなってしまう。 http://toro.5ch.net/test/read.cgi/tech/997345868/755

756: デフォルトの名無しさん [sage] 02/11/13 17:10 >>754 多分 748 宛てだと思われ。 レス番号と間違えてコメント先頭のポインタを書いてしまう間違いは漏れも時々 やってしまう。 http://toro.5ch.net/test/read.cgi/tech/997345868/756

757: 736 [] 02/11/13 17:30 なんか昨日から粘着が居るが >753 >分からんヤツやな、、、 あんたほどでは（Ｗ >refする前に、oobjectが生きてて、refできるか確かめないかんやろ。 確かめた時生きてても、じゃあ参照しようとしたら死んでる罠 確かめるときに参照かうんと増やす何て言うなよ（Ｗ >755 >参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかってる? それは当然ですね。 >これは本来アトミックな処理なので、別スレッドに渡すってのも 別のスレッドに渡すのではなく、 あるスレッドAが参照カウントを持つOのインスタンスをつくって、 別のスレッドBがそのオブジェクトをもらおうとしたらば、 Aはもう要らないとOを破棄しようとしている最中だったわけです。 http://toro.5ch.net/test/read.cgi/tech/997345868/757

758: デフォルトの名無しさん [sage] 02/11/13 17:38 >>753 736 にはもう何も言わなくていいよ。 十分答え出てるのに見ようとしないんだから。 http://toro.5ch.net/test/read.cgi/tech/997345868/758

759: デフォルトの名無しさん [sage] 02/11/13 17:39 >>757 > 別のスレッドに渡すのではなく、 「渡す」つってんのはインスタンス自体じゃなくて参照のことをいってんだけど。 ポインタといったほうがいい? > あるスレッドAが参照カウントを持つOのインスタンスをつくって、 > 別のスレッドBがそのオブジェクトをもらおうとしたらば、 この「もらおうとした」ってどういう状態を考えてるわけよ。 スレッドBはOのインスタンスo1に対する参照を受け取ってないわけ? もし受け取ってるんならその時点でカウントしないとだめぽ。 http://toro.5ch.net/test/read.cgi/tech/997345868/759

760: 736 [] 02/11/13 18:22 >「渡す」つってんのはインスタンス自体じゃなくて参照のことをいってんだけど。 >ポインタといったほうがいい? 「渡す」というのは、あるスレッドAがインスタンスOの参照(カウントが増えた状態)を、別のスレッドB がアクセスできるようにするという意味で使いました。 そうではなくて、スレッドAの預かり知らぬところで、スレッドBがインスタンスOを コピー(の過程で参照化運とは増える)して使おうとするということです。 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた わけです。 >758 そういうなら、参照カウント使ったクラスうｐしてみそ。逃げますか？（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/760

761: 758 [sage] 02/11/13 18:43 >>760 逃げる。 そしておまいは困る。ザマーミロ。 http://toro.5ch.net/test/read.cgi/tech/997345868/761

762: デフォルトの名無しさん [釣りやろか、、 sage ] 02/11/13 18:47 ＞確かめた時生きてても、じゃあ参照しようとしたら死んでる罠 もう一度だけ言うぞ。 「確かめる」と「ref()呼ぶを」、一つのLock内でやれ。 もちろん、releaseの呼び出しにも、おなじLockをかけろ。 それでも、refcountが0になるなら、releaseを呼びすぎているだけ。 http://toro.5ch.net/test/read.cgi/tech/997345868/762

763: 736 [] 02/11/13 19:03 そんなに広い範囲でロックかけないで済む方法ってないの? http://toro.5ch.net/test/read.cgi/tech/997345868/763

764: デフォルトの名無しさん [sage] 02/11/13 19:13 話してる前提が違うんじゃない？ >method1() {lock(); delete str; str = 0; unlcok(); } が method1() {lock(); delete this; /*this = 0;XXX*/ unlcok(); } だから、method2()のifがそもそも出来ないという話 http://toro.5ch.net/test/read.cgi/tech/997345868/764

765: デフォルトの名無しさん [ sage ] 02/11/13 19:44 lock() str->release(); str = NULL; unlock(); http://toro.5ch.net/test/read.cgi/tech/997345868/765

766: デフォルトの名無しさん [ sage ] 02/11/13 19:44 >763 762のlockはそんなに広くないはずだが。 http://toro.5ch.net/test/read.cgi/tech/997345868/766

767: デフォルトの名無しさん [sage] 02/11/13 21:20 >>736 参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、 ref を呼び忘れてる。 参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、 それは通常の参照じゃなく、弱い参照だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/767

768: デフォルトの名無しさん [sage] 02/11/13 23:15 >>736 そもそも、スレッドが生きているかどうか分からないオブジェクトへの ポインタを受け取ること自体に問題があるような。まさか、 スレッドA: p = new クラス(); Bに渡す(p); p->release(); スレッドB: p = Aから受け取る(); p->ref(); というコードを書いていないだろうな？もしそうなら構造上の問題。 Bから見える場所にpを格納したなら、その分の参照カウントを数えなくては ならない。それって本質的にはシングルスレッドでも同じことだけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/768

769: デフォルトの名無しさん [sage] 02/11/13 23:23 > あるスレッドAが参照カウントを持つOのインスタンスをつくって、 COM知ってさえいれば・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/769

770: デフォルトの名無しさん [sage] 02/11/13 23:24 つか、スレッドＢに渡されたことをどうやってＡは知るんだ？ http://toro.5ch.net/test/read.cgi/tech/997345868/770

771: デフォルトの名無しさん [sage] 02/11/13 23:31 >>770 普通Aがそれを知る必要は無いと思うが？ 単にBが自分でディクリメントすればいいだけで。 http://toro.5ch.net/test/read.cgi/tech/997345868/771

772: デフォルトの名無しさん [sage] 02/11/13 23:58 なんか皆さん盛り上がってますが… >>745 >>769に同意。 リファレンスカウントのサンプルを見たければCOMを勉強すればよい。 それと。日本語で一所懸命書かれてもどうにも伝わりにくいようですな。 C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。 http://toro.5ch.net/test/read.cgi/tech/997345868/772

773: デフォルトの名無しさん [sage] 02/11/14 00:03 >>760 > 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを > (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた > わけです。 そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し てしまうというのはバグ。 http://toro.5ch.net/test/read.cgi/tech/997345868/773

774: デフォルトは上限無しさん [ふぅ] 02/11/14 01:03 Guru of the Week! Reference Counting - Part III (Multithreading!) http://www.gotw.ca/gotw/045.htm Reference Counting - Part I http://www.gotw.ca/gotw/043.htm Reference Counting - Part II http://www.gotw.ca/gotw/044.htm http://toro.5ch.net/test/read.cgi/tech/997345868/774

775: デフォルトの名無しさん [sage] 02/11/14 01:23 おまえらスレッド立てすぎです。 http://toro.5ch.net/test/read.cgi/tech/997345868/775

776: デフォルトの名無しさん [sage] 02/11/14 01:25 >>775 http://pc3.2ch.net/test/read.cgi/tech/997345868/515-516 http://toro.5ch.net/test/read.cgi/tech/997345868/776

777: 775 [sage] 02/11/14 01:38 >>776、禿同 マルチスレッド掲示板はやればやるほど スレッドをsageる方向で書込みしたくなるという面白い側面がありますね。 http://toro.5ch.net/test/read.cgi/tech/997345868/777

778: デフォルトの名無しさん [sage] 02/11/14 01:48 この間ようやくプ逝１も sage を覚えたようですが http://toro.5ch.net/test/read.cgi/tech/997345868/778

779: デフォルトの名無しさん [sage] 02/11/14 06:43 VC++の_beginthreadでプログラムを書いてるのですが 親スレッドから子スレッド(以後スレ)を10本同時進行で走らせていて、すべての処理が終った時 子スレの呼び出しの前に変数でフラグを立てておき、そのスレの最後でフラグをONにし、 親スレでそれを確認してからスレを終わるように処理を書いているのですが、 親スレで子スレのフラグを確認している最中に子スレが書き込みすると処理が停止してしまいます。 (デバックしてみるとその付近で停止したりしなかったりする) このスレのどこかで参照は同時に行ってもかまわないようなレスをみたのですが(記憶が確かなら…) 同時書きこみでない場合(書き込み中を参照)でもだめなのでしょうか？ クリティカルセッション等やらねばダメなのでしょうか？ それともこのような設計が悪いのでしょうか・・ http://toro.5ch.net/test/read.cgi/tech/997345868/779

780: 779 [sage] 02/11/14 06:48 >>776 >マルチスレッドプログラミングは、やればやるほど >スレッドを減らす方向に設計したくなるという面白い側面がありますね 私もスレッドにはうんざりですｗ まぁ設計が悪いんでしょうが・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/780

781: デフォルトの名無しさん [sage] 02/11/14 07:20 >>779 DQNは使うな つーか、一冊でも参考書読め http://toro.5ch.net/test/read.cgi/tech/997345868/781

782: 779 [sage] 02/11/14 07:31 よーくデバックすると原因が見つかりました。。^^; 長文書いたにもかかわらずすいません・・ 後余談ですが、デバック中に子スレッドでconnect、closesocketを何度かやっていると ある一定回数(かなりの回数)を超えた時、connectが出来ない状態になりました。 何らかのエラーが発生した場合そのエラーを表示するようにプログラムを 書いているのですが全く表示されません。 Socketの処理は居たってシンプルなもので、スレッドとは別で行っているのでバグは無いと思うのですが・・。 このような事は通常起こり得るのでしょうか？ http://toro.5ch.net/test/read.cgi/tech/997345868/782

783: 736 [] 02/11/14 10:50 どうして、参照カウントが増えた後の話にしたがるのか… http://toro.5ch.net/test/read.cgi/tech/997345868/783

784: デフォルトの名無しさん [] 02/11/14 11:07 >765 >766 参照カウントを持つオブジェクトのリストがあって、追加・削除、参照(+そのための検索) を行おうとすると、それぞれでリスト全部ロックしないと… まあ、注目してるノードとその前後だけロックというのも有りうるけど面倒すぎる。 リスト自体が要素すうもってるし。 >767 参照できるようにする過程での話です。 参照カウントインクリメント不足は、お腹一杯。 >768 スレッドBのAから受け取る()は、どういう処理? そのなかで、当然Mutexとかで排他制御して参照カウント増やすんでしょ? その瞬間の話。 >769 実はCOMです。 COMのモジュール内で持ってる情報の管理でつまずいてる。 769はSTAだけつかってなさい。 http://toro.5ch.net/test/read.cgi/tech/997345868/784

785: デフォルトの名無しさん [] 02/11/14 11:11 >772 ちみもSTAだけつかってなさい。 > C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。 そいでは、>774の Reference Counting - Part III (Multithreading!) http://www.gotw.ca/gotw/045.htm から String::~String() { 　　bool bDelete = false; 　　data_->cs.Lock(); //--------------------------- 　　if( data_->refs == Unshareable || --data_->refs < 1 ) 　　　　bDelete = true; 　　data_->cs.Unlock(); //------------------------- 　　if( bDelete) 　　　　delete data_; } String::String( const String& other ) { 　　bool bSharedIt = false; 　　other.data_->cs.Lock(); //--------------------- 　　if( other.data_->refs != Unshareable ) { 　　　　bSharedIt = true; 　　　　data_ = other.data_; 　　　　++data_->refs; 　　} 　　other.data_->cs.Unlock(); //------------------- 　　if( !bSharedIt ) 　　　　data_ = new StringBuf( *other.data_ ); } (つづく) http://toro.5ch.net/test/read.cgi/tech/997345868/785

786: 736=784=785 [] 02/11/14 11:23 Sharable/Unsharableは置いといて、 Thread A　　　　　　　　　　　　　Thread B delete O1呼び出し　　　　　　　　　O2 = O1 (otherがO1) data_->cs.Lock();　　　　　　　　　other.data_->cs.Lock() if (--data_->refs < 1) 　　bDelete = true; data_->cs.Unlock(); if (bDelete)　　　　　　　　　　　　　data = other.data; 　　delte data;　　　　　　　　　　　　++data_->refs; 　　　　　　　　　　　　　　　　　　　　　other.data_cs.Unlock() 例のコードではStringなので、ロック後解放済みだったら空の文字列 を返せばよいのですが、実際には目的のデータであることを確認後 Thread BはO1のコピーのO2を手に入れようとしているので困ってます。 目的のデータがあるかどうかの検索の最初から、コピーを手に入れるまで と解放処理を呼び出すのもまるっきり排他制御すればできるのは明らかで すが、極端にパフォーマンスが落ちてしまいます。 http://toro.5ch.net/test/read.cgi/tech/997345868/786

787: 736 [] 02/11/14 11:26 >>773 > そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って > カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し > てしまうというのはバグ。 はぁー。 受け取る処理ってどうやるのさ? >774 これからよく読んでみます。 ありがと。 http://toro.5ch.net/test/read.cgi/tech/997345868/787

788: デフォルトの名無しさん [sage] 02/11/14 11:27 >>786 > Thread A　　　　　　　　　　　　　Thread B ここでBは既にO1への参照を持ってんだろ? > delete O1呼び出し　　　　　　　　　O2 = O1 (otherがO1) http://toro.5ch.net/test/read.cgi/tech/997345868/788

789: 736 [sage] 02/11/14 11:34 O1は、スレッド間で共有しているリスト中の要素としてある。 O2=O1は、そのリストから目的の物を検索して取り出す処理の中。 http://toro.5ch.net/test/read.cgi/tech/997345868/789

790: デフォルトの名無しさん [sage] 02/11/14 11:35 マルチスレッドのプログラムで 素朴リファレンスカウントGCをやるなら、 すさまじい細粒度ロックで効率が低下するのは 覚悟しなきゃ。 (普通のGCを使ったほうがずっと速いよ。) http://toro.5ch.net/test/read.cgi/tech/997345868/790

791: デフォルトの名無しさん [sage] 02/11/14 11:53 >>789 やっぱりおかしいな。リストがStringを持ってるわけだろ？ それで、Thread Aがリストから要素を削除したら~String()が呼ばれる わけだが、その前にThread Bがリストの要素への参照を持ってるなら 参照カウントは2になってなきゃおかしい。 こういうことするなら、当然文字列を指す可能性のあるオブジェクト 全部にリファレンスカウント付けて管理してるんだろ？ http://toro.5ch.net/test/read.cgi/tech/997345868/791

792: デフォルトの名無しさん [sage] 02/11/14 11:58 そうか。Stringというより GarbageCollectedというスマートポインタを作って、 ヒープのオブジェクト全部GarbageCollectedを継承するように するんだな。 そして、リストの検索とかやるときは、１つ１つの要素を ロック・ref++・アンロック、ロック・ref--・アンロックすると。 http://toro.5ch.net/test/read.cgi/tech/997345868/792

793: デフォルトの名無しさん [sage] 02/11/14 12:21 >>789 もしかして 「排他制御せずにリストにアクセスしたら、変になるんですけど。」 って言ってる？ スレッドAがリスト中のO1を削除するには、 list.remove(index) あるいは list.remove(O1) スレッドBがO1のコピーを作るには、 O2 = list.get(index) だよな？ で、この get と remove はロックを使わずやりたいと。 そういうことか？ http://toro.5ch.net/test/read.cgi/tech/997345868/793

794: 736 [sage] 02/11/14 12:31 >791 >その前にThread Bがリストの要素への参照を持ってるなら >参照カウントは2になってなきゃおかしい。 リストの要素への参照とは? O1がそれだと言っているのか（Ｗ >793 >で、この get と remove はロックを使わずやりたいと。 >そういうことか？ そう。 でも、 >「排他制御せずにリストにアクセスしたら、変になるんですけど。」 という事じゃない。 removeで要素中のO1は削除されるけど、Thread BがO2を手に入れていれば O1-+ 　　+-->ref:2,data:"ABC" O2-+ から O2---->ref:1,data:"ABC" となり、他のスレッドは、もはやこのデータにアクセスできないが、 Thread BはO2から使える。O2が不要になって破棄したら、データ本体も解放される。 http://toro.5ch.net/test/read.cgi/tech/997345868/794

795: デフォルトの名無しさん [ sage ] 02/11/14 12:37 リスト操作たるgetとremoveにlockかけんかったら、 そいつらが平行したらあぼーんちゃうの。 まあ、「いや、実は〜」とかいって 新状況が出てくるのかも知らんけど(ﾜﾗ http://toro.5ch.net/test/read.cgi/tech/997345868/795

796: デフォルトの名無しさん [sage] 02/11/14 15:34 >>755で > 参照が増減するたびに必ずカウンタも同期しなきゃ行けないってこと、わかっ > てる? これは本来アトミックな処理なので、 と書いてある意味分かんないのか? >>789 > O2=O1は、そのリストから目的の物を検索して取り出す処理の中。 てんなら、その処理中での参照の追加とカウントの増加は原理的に(そのオブ ジェクトに対する)排他処理は必須ってことなんだが。 http://toro.5ch.net/test/read.cgi/tech/997345868/796

797: デフォルトの名無しさん [] 02/11/14 15:42 「getしてO1の参照先のref countが増える」までが アトミックに行われないとまずいね。 getが返すべきO1を得た後で、かつO1のrefが増える前にrefがゼロに なっちゃう。 やはり、 ・リスト全体にmultiple-readers-single-writer lockをかける。 ・リストの要素１つ１つに排他的ロックをかける。 のどちらかが必須。 http://toro.5ch.net/test/read.cgi/tech/997345868/797

798: デフォルトの名無しさん [] 02/11/14 15:50 >>796 禿同 getの中で「注目してるオブジェクト」を示すポインタが あれば、そいつの参照も数えるべき。 あるオブジェクトを指す変数がある瞬間に３つあるなら (たとえば「リストから」「Thread Aの局所変数から」 「Thread Bの局所変数から」)、参照カウントはその瞬間 ３でないと間違い。 http://toro.5ch.net/test/read.cgi/tech/997345868/798

799: デフォルトの名無しさん [sage] 02/11/14 20:52 >>784 (=783?) >実はCOMです。 >COMのモジュール内で持ってる情報の管理でつまずいてる。 COM扱っててこの有様は信じられない。 http://toro.5ch.net/test/read.cgi/tech/997345868/799

800: 736 [sage] 02/11/14 21:27 >796 未だに問題のポイントがわかってない言語障害者が居ますね。 >797 やっぱり、そうなっちゃいますかね。 >799 COMは関係なかろう、STAならInterlock何かする必要無いし、 そうでなければ、COMでも同じ。 http://toro.5ch.net/test/read.cgi/tech/997345868/800

801: デフォルトの名無しさん [sage] 02/11/14 21:44 ふつーのGC使えば、誤爆開放しちゃうdangling pointer問題からは 逃れられる。 でも、２人が同時にリストにあぷデートに行ったらどうやっても ロック必須だけどナー http://toro.5ch.net/test/read.cgi/tech/997345868/801

802: デフォルトの名無しさん [sage] 02/11/14 22:05 なんか禿しく釣られまくったような気がしてきた…。 http://toro.5ch.net/test/read.cgi/tech/997345868/802

803: デフォルトの名無しさん [sage] 02/11/14 22:17 ところでReadWriteLockでスタベーションフリーでLockのUpgrade/Downgradeも できるようなの誰か知らんか？ http://toro.5ch.net/test/read.cgi/tech/997345868/803

804: デフォルトの名無しさん [sage] 02/11/14 22:20 >>736 考え方おかしいよ。 管理する側とされる側がごっちゃになってる。 そもそもdelete後に破棄されたインスタンスの排他制御 オブジェクトを参照しようとしてる事をおかしいと思わないの？ http://toro.5ch.net/test/read.cgi/tech/997345868/804

805: デフォルトの名無しさん [] 02/11/14 22:28 便乗で質問です。 スレッド間で、GC(インクリメンタルなマーク&スイープ)で管理された 共有領域のメモリオブジェクトを使いたいんですが、メモリオブジェクト にはアクセスする度に排他制御しないといけませんよね？ 参照するだけなら不要なのはわかるんですが、ポインタを繋ぎ変えたりも したいので、結局双方でロックしてないと駄目ですよね。 素直に組むと、メモリオブジェクトの粒度が小さいので排他制御にかなり の時間が割かれてしまいそうなんですが、良い方法はないでしょうか。 素人考えで思いついたのは、スレッド毎にローカルなメモリオブジェクト 領域を使って、処理が完了したら、その結果を共有メモリオブジェクト 領域に移すという方法で、排他制御は共有メモリにアクセスするとき のみ掛けるというものですが、この方法だとスレッド毎にGCが必要な気が します。 もっと一般的な方法があったらお願いします。 http://toro.5ch.net/test/read.cgi/tech/997345868/805

806: デフォルトの名無しさん [sage] 02/11/15 01:09 >>805 読むだけなら排他制御は不要だよ。 整数や文字を書き込むときも（共有変数以外は）不要。 ポインタを書いたときはライトバリアでGCに通知。 これも別に排他制御はいらない。たとえばスレッドごとにキューを作って、 ページ単位とかでまとめて渡せばよい。 http://toro.5ch.net/test/read.cgi/tech/997345868/806

807: 805 [] 02/11/15 03:22 >>806 ありがとうございます。 ライトバリアでマークする経路を保証するって事ですよね。 共有領域とローカルの区別をする手段が思いつかない(複数 ブロックにまたがってる)んで、改竄個所を全部保護する様に 書き直さないとまずいのかな。 ちょっと考えてみます。 http://toro.5ch.net/test/read.cgi/tech/997345868/807

808: デフォルトの名無しさん [sage] 02/11/15 03:25 ヒープに置くポインタはすべて template Pointer<class T> ... みたいなオブジェクトにして、コピーコンストラクタ でライトバリアをかければよいんじゃないだろうか。 http://toro.5ch.net/test/read.cgi/tech/997345868/808

809: 736 [sage] 02/11/15 10:43 >804 頭おかしいよ。 こんなのどこにでもある。見たこと無いのか? http://toro.5ch.net/test/read.cgi/tech/997345868/809

810: デフォルトの名無しさん [sage] 02/11/15 10:55 >>736 何人もの人間が否定してるんだから、おかしいのはお前だろ(笑 http://toro.5ch.net/test/read.cgi/tech/997345868/810

811: 736 [sage] 02/11/15 11:23 じゃあ、COMもおかしいのか? http://toro.5ch.net/test/read.cgi/tech/997345868/811

812: デフォルトの名無しさん [sage] 02/11/15 11:49 >>809 「どこにでもある」 が 「おかしくない」 の理由には全然ならない事に気付け。 つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな サンプルに見舞われてるんだな。 >>811 おかしいのは COM を把握してないのにわかったつもりになってるあんたの頭。 つーか、教えを乞う立場だったら、もっと謙虚になれ。 主観を捨てろ。 答えへのポインタはもう不必要なほど出ているのに、あんたはそれを全部捨てている。 http://toro.5ch.net/test/read.cgi/tech/997345868/812

813: 736 [sage] 02/11/15 12:24 >812 >つーか、教えを乞う立場だったら、もっと謙虚になれ。 共有しているオブジェクトの集合に丸ごとロックかけずに、 各オブジェクトの参照カウントだけで済むかがポイントなのに、 参照カウントのインクリメント不足だとか、 COMを知ってればとか、 おんなじ事 おんなじ事 おんなじ事 おんなじ事 ばかーーーり。 しつこつ しつこく しつこーーーーく 同じこと繰り返す粘着が多くてウンザリ。 getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。 参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。 じゃあ、参照を手に入れる処理を書いてみろというと、とたんに逃げ出す。 どうしてポイントがずれた香ばしい奴が多いのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/813

814: 736 [sage] 02/11/15 12:26 >812 >「どこにでもある」 が 「おかしくない」 の理由には全然ならない事に気付け。 >つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな >サンプルに見舞われてるんだな。 これ見たこと無いか? static ULONG WINAPI Increment(LPLONG p) {return InterlockedIncrement(p);} static ULONG WINAPI Decrement(LPLONG p) {return InterlockedDecrement(p);} ULONG InternalAddRef() { 　return _ThreadModel::Increment(&m_dwRef); } ULONG InternalRelease() { 　return _ThreadModel::Decrement(&m_dwRef); } STDMETHOD_(ULONG, AddRef)() {return InternalAddRef();} STDMETHOD_(ULONG, Release)() { 　ULONG l = InternalRelease(); 　if (l == 0) 　　delete this; 　return l; } まあ、君のコードの中では、 static ULONG WINAPI Increment(LPLONG p) {return ++(*p);} static ULONG WINAPI Decrement(LPLONG p) {return --(*p);} しか使われないと思うが（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/814

815: デフォルトの名無しさん [ sage ] 02/11/15 12:37 736の、これまでの発言で推測できること。 1.listでCOM objectを束ねているらしい 2.list内のあるCOM objectに対して、 　releaseとrefが(release->refの順で)発生して死ぬようだ 3.list全体に対するlockはかけたくないらしい 　(listが持つCOM objectに対する個々のロックは可能みたい？) 736の発言だけで、この問題がわかるかってーの。 それを736の時点で言えば、まだ混乱は少なかっただろうに。 変に情報を出し惜しむから、おなじ事をしつこく何度も 言われる羽目になる。おまけに自分のことを棚に上げて しつこいとか、ポイントがずれてるとか、香ばしいとか言うし。 http://toro.5ch.net/test/read.cgi/tech/997345868/815

816: 736 [sage] 02/11/15 12:40 それで？ http://toro.5ch.net/test/read.cgi/tech/997345868/816

817: デフォルトの名無しさん [ sage ] 02/11/15 12:42 で、815であげた推測は正しいのかい？ というか、コードだせ、コード。問題の起こる、 必要最小限の、736の書いたコードを。 http://toro.5ch.net/test/read.cgi/tech/997345868/817

818: 736 [sage] 02/11/15 12:44 738 ：デフォルトの名無しさん ：02/11/12 20:25 参照カウントを0から始めたに100スレッド 740 ：デフォルトの名無しさん ：02/11/12 21:24 ref() と release() が互いに排他してなきゃ動くわけないじゃん。 742 ：デフォルトの名無しさん ：02/11/12 21:57 あるオブジェクトに触れるスレッドが一つふえたら そのオブジェクトの参照カウントをageておく必要があることに 気づいてないに1000はらたいら 743 ：デフォルトの名無しさん ：02/11/12 21:58 ＞739 それもなんだかおかしな動作だな。 refを発行する、というのは、どっかからobjectを貰ってきてるわけだろ。 で、releaseを発行するということは、所有権の一端を持っているわけだよな。 それで、deleteが実行されるというのは、 「refcount == 0かもしれないobjectが渡ってきた」 「release発行しすぎ」 ってなわけだろ。refするタイミングとか、考え直した方がいいんでないか？ 745 ：デフォルトの名無しさん ：02/11/12 22:52 736はひょっとしてCOMを知らない？ 747 ：デフォルトの名無しさん ：02/11/13 10:35 「別のスレッドが使うためにコピーを作る」ときに 「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。 「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。 http://toro.5ch.net/test/read.cgi/tech/997345868/818

819: 736 [sage] 02/11/15 12:44 750 ：デフォルトの名無しさん ：02/11/13 11:21 ひょっとしてrefcountをさらにポインタや参照で管理しようとしてないか? そんなのrefcountの意味が全くないぞ。根本的にrefcountについて誤解してるだろ。 751 ：デフォルトの名無しさん ：02/11/13 11:28 >>750 俺もそんな気がして来た。グローバルなオブジェクトや静的なオブジェクトを 参照カウントでやろうとしてるような気もするし。 753 ：デフォルトの名無しさん ：02/11/13 15:40 分からんヤツやな、、、 refする前にreleaseが発行されてrefcount==0になる 可能性があるなら、refする前に、oobjectが生きてて、 refできるか確かめないかんやろ。その結果、objectが 死んでるなら、refしてobject渡すのは諦めなアカン。 　で、そこでobjectが死んでるのが間違いなら、releaseか refの発行の仕方がオカシイんや。 http://toro.5ch.net/test/read.cgi/tech/997345868/819

820: 736 [sage] 02/11/15 12:45 767 ：デフォルトの名無しさん ：02/11/13 21:20 >>736 参照カウントが 1 のオブジェクトを複数のスレッドから参照してる時点で、 ref を呼び忘れてる。 参照回数0 のオブジェクトに到達することが正しい振る舞いだとしたら、 それは通常の参照じゃなく、弱い参照だ。 769 ：デフォルトの名無しさん ：02/11/13 23:23 > あるスレッドAが参照カウントを持つOのインスタンスをつくって、 COM知ってさえいれば・・・ 772 ：デフォルトの名無しさん ：02/11/13 23:58 なんか皆さん盛り上がってますが… >>745 >>769に同意。 リファレンスカウントのサンプルを見たければCOMを勉強すればよい。 それと。日本語で一所懸命書かれてもどうにも伝わりにくいようですな。 C言語で（擬似コードでも可）書いた方が意図が伝わると思いますが。 773 ：デフォルトの名無しさん ：02/11/14 00:03 >>760 > 参照を受け取った時には、当然参照カウントは増えていますが、Oの参照カウントを > (クリティカルセクション獲得後)増やそうとしたら、スレッドAが解放してしまっていた > わけです。 そりゃカウントミスってる。AがOを持ってるところでBがOの参照を受け取って カウントも増やしたんなら、カウントは2以上のはずだ。その状態でAが解放し てしまうというのはバグ。 http://toro.5ch.net/test/read.cgi/tech/997345868/820

821: デフォルトの名無しさん [sage] 02/11/15 12:48 736 荒らしｹﾃｰｲ （いや、元々そうだったという説もあるが・・・） という訳で出て逝ってくれ。 http://toro.5ch.net/test/read.cgi/tech/997345868/821

822: 736 [sage] 02/11/15 12:51 君らのしつこさを確認させてやっただけだよ http://toro.5ch.net/test/read.cgi/tech/997345868/822

823: デフォルトの名無しさん [ sage ] 02/11/15 12:53 ( ´，_ゝ｀)ﾌﾟッ http://toro.5ch.net/test/read.cgi/tech/997345868/823

824: 736 [sage] 02/11/15 12:58 結局誰も判らんのか。それならそう言えよ無能者ども。 http://toro.5ch.net/test/read.cgi/tech/997345868/824

825: デフォルトの名無しさん [sage] 02/11/15 13:00 >>822 あのさあ、 しつこいのは　お　ま　え　（ｗ 消えろ http://toro.5ch.net/test/read.cgi/tech/997345868/825

826: デフォルトの名無しさん [sage] 02/11/15 13:03 >>813 > 共有しているオブジェクトの集合に丸ごとロックかけずに、 > 各オブジェクトの参照カウントだけで済むかがポイントなのに、 参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 してないのはシングルスレッドを前提にしてる場合だけ。 わかった? > 参照カウントのインクリメント不足だとか、 > COMを知ってればとか、 > おんなじ事 おんなじ事 おんなじ事 おんなじ事 ばかーーーり。 > しつこつ しつこく しつこーーーーく 同じこと繰り返す粘着が多くてウンザリ。 なんでおんなじ事をこんなにしつこく説明してやらなきゃならんのか…。 > getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。 > 参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。 そのアトミックなgetにカウントのインクリメントを含めてないからバグって んだろが。 http://toro.5ch.net/test/read.cgi/tech/997345868/826

827: 736 [sage] 02/11/15 13:07 まだ言ってるのか。 >参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 >してないのはシングルスレッドを前提にしてる場合だけ。 >わかった? void ref() { EnterCriticalSection(&m_mutex); 　InterlockedIncrement(&m_ref);　 LeaveCriticalSection(&m_mutex); } void release() { EnterCriticalSection(&m_mutex); 　if (InterlockedDecrement(&m_ref) == 0) { 　　delete this; 　} LeaveCriticalSection(&m_mutex); } としたら満足か？（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/827

828: 736 [sage] 02/11/15 13:09 >826 おまえ、InterlockXXってなんのためにあるのか知らんだろ。 知らない奴に限って、無駄なレスを返しやがる。 http://toro.5ch.net/test/read.cgi/tech/997345868/828

829: デフォルトの名無しさん [sage] 02/11/15 13:12 としたら満足か、って・・・ 一体何の為にここに質問に来たんだ？ http://toro.5ch.net/test/read.cgi/tech/997345868/829

830: デフォルトの名無しさん [sage] 02/11/15 13:17 736の無能っぷりをさらけ出すスレはここですか？ >>837 >EnterCriticalSection(&m_mutex); >　InterlockedIncrement(&m_ref);　 >LeaveCriticalSection(&m_mutex); クリティカルセクション張ってるんだから、 インターロック不要なんだけど。 >EnterCriticalSection(&m_mutex); >　if (InterlockedDecrement(&m_ref) == 0) { >　　delete this; >　} >LeaveCriticalSection(&m_mutex); 自分で書いてておかしいと思わないのかなあ・・ http://toro.5ch.net/test/read.cgi/tech/997345868/830

831: 736 [sage] 02/11/15 13:21 >>836 あのなあ、 >>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 >>してないのはシングルスレッドを前提にしてる場合だけ。 >>わかった? というのは読めないのか。お前は、自然言語にたいする理解力は０だな。 ロックかけなきゃだめだと言ってるやつがいるから、ロックしたまで。 なーんの解決にもならんし、もともと、Interlockしてるから不要なんだがな。 http://toro.5ch.net/test/read.cgi/tech/997345868/831

832: 736 [sage] 02/11/15 13:21 >830 だわ http://toro.5ch.net/test/read.cgi/tech/997345868/832

833: 736 [sage] 02/11/15 13:23 で？８２６も逃げたのか。全く都合が悪くなると逃げて…自分の発言に席にもてよ。 どうせ、別人のフリしてまた別の事言い出すんだろうが http://toro.5ch.net/test/read.cgi/tech/997345868/833

834: 736 [sage] 02/11/15 13:26 ん？deleteまではロックしなきゃダメかな。 まあ、どのみちref()でロック獲得したときに、解放済みというのは避けられんが。 http://toro.5ch.net/test/read.cgi/tech/997345868/834

835: デフォルトの名無しさん [sage] 02/11/15 13:28 >>827 > としたら満足か？（Ｗ で、バグは直ったのか? 漏れが満足したからってバグが消えるわけじゃないぞ。 void Item::ref() { 　InterlockedIncrement(&m_ref);　 } Item* List::get() { EnterCriticalSection(&m_mutex); Item* p = ...; p->ref(); LeaveCriticalSection(&m_mutex); return p; } この例で行くとListのget()とremove()で競合が起きるんだろ? ならListのほうで排他処理をするのが自明の理。 http://toro.5ch.net/test/read.cgi/tech/997345868/835

836: 736 [sage] 02/11/15 13:34 やっぱり、List::get()でリストの検索処理が丸ごとロックするしかないのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/836

837: デフォルトの名無しさん [sage] 02/11/15 13:40 (´-`).｡ｏＯ(100レスかけてようやく染み込んだのか) http://toro.5ch.net/test/read.cgi/tech/997345868/837

838: 736 [sage] 02/11/15 13:49 それ以外に無いのか聞いてんだが。 ここのいる連中じゃ無理のようだ（Ｗ http://toro.5ch.net/test/read.cgi/tech/997345868/838

839: 736 [sage] 02/11/15 13:53 >812 >「どこにでもある」 が 「おかしくない」 の理由には全然ならない事に気付け。 >つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな >サンプルに見舞われてるんだな。 ８１２も逃げたようだな。逃げ足の速い連中だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/839

840: デフォルトの名無しさん [sage] 02/11/15 14:07 >>838 > それ以外に無いのか聞いてんだが。 散々いわれてんのに。>>762とか>>785とか。 大体間接的に渡すって話自体>>789くらいでいきなりだし。 >>839 > ８１２も逃げたようだな。逃げ足の速い連中だ。 いつまでも君の相手してらんないしね。 漏れもそろそろ出かけなきゃならないんでバイバイ。 http://toro.5ch.net/test/read.cgi/tech/997345868/840

841: デフォルトの名無しさん [] 02/11/15 14:27 winでのTerminateThreadと同じような 関数はunixにありますか？ http://toro.5ch.net/test/read.cgi/tech/997345868/841

842: デフォルトの名無しさん [sage] 02/11/15 14:38 pthreadならpthread_cancel()かな。TerminateThreadと違って必ずしも即座に 終了するわけじゃないけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/842

843: デフォルトの名無しさん [] 02/11/15 14:44 教えて下さい。 pthread_cancel()を実行すると 実行されたスレッドの終了はいつになるのですか？ http://toro.5ch.net/test/read.cgi/tech/997345868/843

844: デフォルトの名無しさん [sage] 02/11/15 14:47 実行してみればわかる http://toro.5ch.net/test/read.cgi/tech/997345868/844

845: 736 [sage] 02/11/15 15:06 >840 またバカが湧いてきた。 >散々いわれてんのに。>>762とか>>785とか。 >762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？ リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。 君のような厨には理解で菌だろうがな。 >大体間接的に渡すって話自体>>789くらいでいきなりだし。 間接的?ハァ?頭大丈夫? 785は俺だ。 たくっ。ろくに読まないでレスするアホウは書くなっつの。 >いつまでも君の相手してらんないしね。 >漏れもそろそろ出かけなきゃならないんでバイバイ。 いや、君みたいなアホウに相手してくれとは言ってないから（Ｗ お呼びでないの（Ｗつか出てくんなっての 大体、レスして何か言われたら自分が誰かわかるように名前に番号入れるもんだろ。 言いっぱなしで自己満足してる厨が多すぎ。 http://toro.5ch.net/test/read.cgi/tech/997345868/845

846: 736 [sage] 02/11/15 15:16 740 ：デフォルトの名無しさん ：02/11/12 21:24 ref() と release() が互いに排他してなきゃ動くわけないじゃん。 826 ：デフォルトの名無しさん ：02/11/15 13:03 >>813 > 共有しているオブジェクトの集合に丸ごとロックかけずに、 > 各オブジェクトの参照カウントだけで済むかがポイントなのに、 参照カウントのインクリメントにはロックは*原理的に*必要不可欠。 してないのはシングルスレッドを前提にしてる場合だけ。 わかった? こういう連中は、 void ref() { 　EnterCriticalSection(&m_cs); 　++m_ref; 　LeaveCriticalSection(&m_cs); } void release() { 　EnterCriticalSection(&m_cs); 　if (--m_ref) == 0) { 　　delete this; 　} 　LeaveCriticalSection(&m_cs); } って書いてるのかな。馬鹿だなー。 こんな事言ってる奴が多いのは　オ　ド　ロ　キ。 もはや都市伝説だな。 http://toro.5ch.net/test/read.cgi/tech/997345868/846

847: 736 [sage] 02/11/15 15:17 おっ！ 830が、慌ててネットで調べ始めた。まあ、自分の馬鹿さ加減を思い知れ。 http://toro.5ch.net/test/read.cgi/tech/997345868/847

848: 736 [sage] 02/11/15 15:21 おっ！ 他にもInterlockだけじゃダメだと思ってる奴も多いな。 まあ、release()のLeaveCriticalSectionがdelete以降なのは論外だが、 void ref() { 　InterlockedIncrement(&m_ref);　 } void release() { 　if (InterlockedDecrement(&m_ref) == 0) { 　　delete this; 　} } じゃだめだと思ってるやつは何か言ってみろ。 どうせ逃げんだろうけどな。 http://toro.5ch.net/test/read.cgi/tech/997345868/848

849: デフォルトの名無しさん [sage] 02/11/15 15:34 void ref() { 　InterlockedIncrement(&m_ref);　// A } void release() { 　if (InterlockedDecrement(&m_ref) == 0) { 　　// B 　　delete this; 　} } B のタイミングで A が呼ばれた場合。 http://toro.5ch.net/test/read.cgi/tech/997345868/849

850: デフォルトの名無しさん [sage] 02/11/15 15:45 void ref() { 　InterlockedIncrement(&m_ref);　// A } void release() { 　if (InterlockedDecrement(&m_ref) == 0) { 　　delete this; 　　// C 　} } C のタイミングで A が呼ばれた場合。 しかし、危険性において 846 のコードは結局 848 と変わらないな。 http://toro.5ch.net/test/read.cgi/tech/997345868/850

851: 736 [sage] 02/11/15 15:48 おいおい、本当にのこのこ出てきたよ。恥ずかしい奴だ。 http://toro.5ch.net/test/read.cgi/tech/997345868/851

852: 736 [sage] 02/11/15 15:50 >しかし、危険性において 846 のコードは結局 848 と変わらないな。 説明してみろよ。わくわく。 Bのところに行くのは、どういう場合さ? http://toro.5ch.net/test/read.cgi/tech/997345868/852

853: デフォルトの名無しさん [sage] 02/11/15 16:01 >８４９ 馬鹿です。 http://toro.5ch.net/test/read.cgi/tech/997345868/853

854: デフォルトの名無しさん [sage] 02/11/15 16:01 晒しage http://toro.5ch.net/test/read.cgi/tech/997345868/854

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

あと 132 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.022s