[過去ﾛｸﾞ]
マルチスレッドプログラミング相談室 (986ﾚｽ)
マルチスレッドプログラミング相談室 http://toro.5ch.net/test/read.cgi/tech/997345868/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
1: デフォルトの名無しさん [] 2001/08/09(木) 17:31 マルチスレッドプログラミング相談室 http://toro.5ch.net/test/read.cgi/tech/997345868/1
860: 859 [sage] 02/11/15 16:14 ごめん、無かった事にして。 http://toro.5ch.net/test/read.cgi/tech/997345868/860
861: 736 [sage] 02/11/15 16:13 m_csってメンバー変数じゃないのか? ref()のEnterCriticalSectionでブロックされてるときに deleteされるのは大丈夫か? 首尾よく、ref()でCriticalSectionに入れてもm_refは不定だぞ。 http://toro.5ch.net/test/read.cgi/tech/997345868/861
862: 736 [sage] 02/11/15 16:16 で？849はやっぱり逃げたのか。 http://toro.5ch.net/test/read.cgi/tech/997345868/862
863: デフォルトの名無しさん [sage] 02/11/15 16:17 ここはすごいITパワーですね。 http://toro.5ch.net/test/read.cgi/tech/997345868/863
864: デフォルトの名無しさん [ sage ] 02/11/15 16:23 ＞838 だから、無いんだって。intのlistを考えてみろよ。 lockしないで、検索処理と、削除処理を併走できるかっつーの。 http://toro.5ch.net/test/read.cgi/tech/997345868/864
865: デフォルトの名無しさん [sage] 02/11/15 16:28 >864 リストなら丸ごとロックしなくてもできる。 http://toro.5ch.net/test/read.cgi/tech/997345868/865
866: 736 [sage] 02/11/15 16:30 >865 と言うと? >864 おい！あるってぞ。言い返せよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/866
867: デフォルトの名無しさん [ sage ] 02/11/15 16:33 別に言い返さないさ。 自身の不明を恥じて、詳細を拝聴するだけサ。 http://toro.5ch.net/test/read.cgi/tech/997345868/867
868: 865 [sage] 02/11/15 16:47 例えば、リストの3番目を削除しようとしている時には、検索処理が4番目以降の要素を 見ているなら同時に動いて問題ない。検索処理が、ちょうど3番目の要素を見ようとしているか 3番目から4番目に移ろうとしている時だけが同時に動けないだけ。 どのみち、要素数とか持っているリストだと同時に複数が書き込めないから、 たかだか一つの要素だけ排他制御できさえすればよい。 http://toro.5ch.net/test/read.cgi/tech/997345868/868
869: デフォルトの名無しさん [sage] 02/11/15 17:02 リストの項目が増えた時、リスト丸ごとのロックと、項目ごとのロックでは、 どっちが速いんだろうか。 http://toro.5ch.net/test/read.cgi/tech/997345868/869
870: [sage] 02/11/15 17:09 >>869 そういうものの定石を適用すると、リストを示すポインタ値を適当にハッシュして16個くらいの ロックに分散させる、てな感じにするんだと思うよ。一要素毎にロックを持つのはリソースを食 うし、あまりぶつからない程度に分散させれば十分だから。 http://toro.5ch.net/test/read.cgi/tech/997345868/870
871: デフォルトの名無しさん [sage] 02/11/15 17:13 >869>870 865が言っているのは、要素毎にロック作らなくても、 同時書き込み無しなら、一つロックがあればいいということだろ。 丸ごとロックしなくても、ロック一つでWriterはReaderと共存(Readerがいなく なるまでまたなくても)できると。 http://toro.5ch.net/test/read.cgi/tech/997345868/871
872: デフォルトの名無しさん [ sage ] 02/11/15 17:16 ＞871 ロックが一つしかないなら、どうやって、 「今削除しようしている所を読んでるreaderがいない＆ readerは削除しようとしている所へ進入しない」って 保証できるん？ http://toro.5ch.net/test/read.cgi/tech/997345868/872
873: 736 [sage] 02/11/15 17:18 それは、16スレッドが同時に書き込めるのか? 各スレッドが別の要素にアクセスするとして。 リストが要素数なんか持ってても大丈夫? 単純なリストならまだしも、空リストとか管理されてると結局その中の 一つのスレッドしか書き込みできない(というか排他制御が必要な)気がするが。 http://toro.5ch.net/test/read.cgi/tech/997345868/873
874: 871 [sage] 02/11/15 17:26 >872 writerは要素の変更じゃ無くて、要素の追加・削除を行うとして。 writerが削除しようとしている要素とかその次の要素の場所を書いとけば、 readerはそれみて何とかできる気がするが。 writerが削除しようとしている要素はすっ飛ばすとか。 追加は先頭でも最後でも問題起きないと思うが。 どっちにしろ、readerはwriterがする事を知っているのが前提で、 汎用ではなく。 http://toro.5ch.net/test/read.cgi/tech/997345868/874
875: 872 [ sage ] 02/11/15 17:27 ひょっとして、readerの数だけの、index/pointerを指している 配列と、その配列全体に対するロックがあれば解決できる話 なのか？ http://toro.5ch.net/test/read.cgi/tech/997345868/875
876: デフォルトの名無しさん [ sage ] 02/11/15 17:33 ＞874 それだと、「削除されるべき場所にいるreader」が、 「『リストの次の要素へ』を発行すること」をどう保証するか、 writerはどう検出するかって問題になるとおもうけど、、 http://toro.5ch.net/test/read.cgi/tech/997345868/876
877: デフォルトの名無しさん [sage] 02/11/15 18:00 ５０年前の並列処理問題を一から学び直す ドキュソPGのスレはここですか？ http://toro.5ch.net/test/read.cgi/tech/997345868/877
878: デフォルトの名無しさん [ sage ] 02/11/15 18:06 >877 ( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ ) http://toro.5ch.net/test/read.cgi/tech/997345868/878
879: デフォルトの名無しさん [sage] 02/11/15 18:48 lock free linked list なんつって http://toro.5ch.net/test/read.cgi/tech/997345868/879
880: 768だけどさあ [] 02/11/15 20:02 分からん奴だなあ。 リストの排他制御と、参照カウントの問題と、参照カウントの 排他が全部ごっちゃになっている時点でもう駄目。 まず、リストに複数スレッドからアクセスするなら、そのリストの どこかに排他入れなきゃ駄目なの。次に、問題の共有オブジェクト はリストからの参照の分があるから、リストに繋がっている間は 参照カウントは常に1以上でなきゃ駄目なの。「見付けた」時点では 「リストの方が」排他されているから、この間に参照カウントを増やそうね。 リストの排他が終わった時点で、参照カウントは2以上だから、この後 リストからremoveされても平気だよね。(ここが768の「Bから見える場所に 云々」ということの意味。)第三に、参照カウントも複数のスレッドから 参照されるから、これも排他しなくちゃならないよね。これはさすがに 分かってるみたいだけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/880
881: 736 [sage] 02/11/15 21:01 お前ら無能すぎ。そんな程度で２ちゃん来てんじゃねーよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/881
882: デフォルトの名無しさん [ sage ] 02/11/15 21:07 ところで、881は何人目の736ですか？ http://toro.5ch.net/test/read.cgi/tech/997345868/882
883: 870 [sage] 02/11/15 21:08 >>873 何への質問だかわからないけど、16っていうマジックナンバーがあるから 870 だと仮定して答える。 「リストから remove 」等の処理に排他制御をかけるとして、ごく素朴な リスト全体にたいしてロックが１つ、という状態では競合が起きた場合に 素直にパフォーマンスが悪化する。並列性が高くなればなるほど競合の可 能性は増し、結局並列動作できない場面が出てくる。 その辺をチューニングする場合の定石として、適当にロックの数を増やす ってのがある。コンテキストスイッチングに比べて排他の対象となる操作 の方が十分重い場合には、寝てるスレッドのことはほぼ無視しても良いの で、CPU の数＋αに分散させれば十分。そうじゃないときは多めにする。 http://toro.5ch.net/test/read.cgi/tech/997345868/883
884: 870 [sage] 02/11/15 21:11 >>849-850 そのタイミングで当該オブジェクトへのアクセスが発生するって思うのは、 参照カウントというものが何であるのかをわかっていないと思う。 そらまあそーいうこともあるだろうケド、その場合呼び出し側がバグって るわけで。 http://toro.5ch.net/test/read.cgi/tech/997345868/884
885: 736 [sage] 02/11/15 21:13 >>881 とうとう偽者まで出てきたか。 http://toro.5ch.net/test/read.cgi/tech/997345868/885
886: 736 [sage] 02/11/15 21:13 適当ほざいてんじゃねーよ 帰って寝てろ ﾜﾗﾜﾗ http://toro.5ch.net/test/read.cgi/tech/997345868/886
887: 736 [sage] 02/11/15 21:16 881=882だろ。 >880 > 第三に、参照カウントも複数のスレッドから > 参照されるから、これも排他しなくちゃならないよね。 どういう風に?(W http://toro.5ch.net/test/read.cgi/tech/997345868/887
888: 736 [sage] 02/11/15 21:17 >886 おまえも881だろ。 >884=870 もうちょっと、説明してくれや。 http://toro.5ch.net/test/read.cgi/tech/997345868/888
889: 736 [sage] 02/11/15 21:18 騙ってまで何がやりたいんだか >880 教科書のコピペはやめようね http://toro.5ch.net/test/read.cgi/tech/997345868/889
890: 元祖736 [sage] 02/11/15 21:18 736増殖中 http://toro.5ch.net/test/read.cgi/tech/997345868/890
891: 736本人 [sage] 02/11/15 21:20 やめろっての。馬鹿がうつる。 http://toro.5ch.net/test/read.cgi/tech/997345868/891
892: 元祖736 [sage] 02/11/15 21:24 >>880 だぁから、そんなのあたりまえだろ。おまえはしらなかったかもしらんが。 そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、 しつこく しつこく しつこーーく 参照カウントのインクリメント不足だと おんなじ事繰り返す厨の集団攻撃が始まっちまったんだよ。 しまいには、ref()とrelease()に排他制御が無いからだと言い出すドアホまで 何人も出てきやがるし。お前達は、お呼びじゃないんだよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/892
893: 870 [sage] 02/11/15 21:25 reference counting ってのは、そのオブジェクトへの「参照」の数を 数えておいて、ゼロになったら誰も見てないから開放〜てなアイデア。 だからカウントがゼロになった後は誰から参照されておらず、どんな メソッド…メンバ関数も呼ばれないわけです。呼んだとしたらそれは 呼び出し側のバグ。 http://toro.5ch.net/test/read.cgi/tech/997345868/893
894: デフォルトの名無しさん [ sage ] 02/11/15 21:41 ＞そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、 736ではそんな話には読めない。最初からそう書けよ。 ＞おんなじ事繰り返す厨の集団攻撃が始まっちまったんだよ。 自業自得 http://toro.5ch.net/test/read.cgi/tech/997345868/894
895: デフォルトの名無しさん [sage] 02/11/15 21:46 >そこを参照カウントに技使って、リストのロックに工夫できないかという話だったのが、 どんどん話が変わっているような。しかも参照カウントとオブジェクトを 参照しているリストなんて、参照カウントを増やすこと以外に全然関係 無いから、工夫なんてまず無理だろう。 http://toro.5ch.net/test/read.cgi/tech/997345868/895
896: デフォルトの名無しさん [sage] 02/11/15 21:47 誰か本物の736を連れ戻してくれよ http://toro.5ch.net/test/read.cgi/tech/997345868/896
897: デフォルトの名無しさん [ sage ] 02/11/15 21:52 ＞881=882だろ。 違いますよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/897
898: デフォルトの名無しさん [] 02/11/15 21:56 だから参照カウントなんて腐った手法使うなって。 http://toro.5ch.net/test/read.cgi/tech/997345868/898
899: 736 [sage] 02/11/15 22:02 >898 ギブアップしたの?(W http://toro.5ch.net/test/read.cgi/tech/997345868/899
900: デフォルトの名無しさん [sage] 02/11/15 22:52 だから最初から言ってるだろ？ 参照カウントなんて使わずにまともなGC使えや。 http://toro.5ch.net/test/read.cgi/tech/997345868/900
901: デフォルトの名無しさん [sage] 02/11/15 23:15 参照カウントか、昔よくやってた。懐かしいな。マルチスレッドでうまく解けるか 自信ないけど…。 スレッド 1 がクリティカルセクションに入って参照カウントを 0 にしようとした 瞬間、別のスレッド 2 がカウントアップしようとクリティカルセクションで ブロックに突入するからまずいんだろうな。同期ブロックに入っている数もカウント しておいて、参照カウントと同期ブロックスレッド数が 0 になったところで初めて 開放すれば良いんじゃなかろうか。 …でも別スレッドからカウントアップ可能ということはそのスレッドから参照が残っ てるってことだからやっぱり無理なのか? CPU 負荷などの影響でカウントアップ側の 処理が遅れたらアウトだもんな。んでもスレッド間での参照の「コピー」時にしっかり カウントアップしてれば問題無いような。 参照カウントと循環参照について IBM に話が載ってるけどこれはガイシュツかいな。 http://www-6.ibm.com/jp/developerworks/java/000721/j_garbage-collection.html http://toro.5ch.net/test/read.cgi/tech/997345868/901
902: デフォルトの名無しさん [sage] 02/11/15 23:39 参照を獲得する処理そのものがアトミックでなければいけない。 つまり、ref や release に到達する時点でそのオブジェクトに対する排他制御が かかってなきゃいけない。それらのメソッドに入ってからでは遅い。 Object* List::get(int index){ criticalSections_[index % 4].enter(); Object* o = items_[index]; if(o != NULL){ o->ref(); } criticalSections_[index % 4].leave(); return o; } void List::remove(index){ criticalSections_[index % 4].enter(); Object* o = items_[index]; if(o != NULL){ o->release(); items_[index] = NULL; } criticalSections_[index % 4].leave(); return o; } こんな感じか？ http://toro.5ch.net/test/read.cgi/tech/997345868/902
903: デフォルトの名無しさん [sage] 02/11/16 00:40 レスがたくさんついていると思ったら、、、 http://toro.5ch.net/test/read.cgi/tech/997345868/903
904: 入門者だけど [] 02/11/16 01:05 本質的には参照カウントのことは関係なくて、参照が複数スレッドで 共有されていれば、その参照自体にも排他をかけなければならない というだけの話だ、という理解で合ってる？ http://toro.5ch.net/test/read.cgi/tech/997345868/904
905: デフォルトの名無しさん [sage] 02/11/16 01:11 そもそもスレッド間で参照を代入するときにちゃんと 参照数 +1 してれば ゼロにはならないのでは? http://toro.5ch.net/test/read.cgi/tech/997345868/905
906: デフォルトの名無しさん [sage] 02/11/16 01:18 >>905 >>742 あれから100以上もひっぱった736の連中、氏ね。 http://toro.5ch.net/test/read.cgi/tech/997345868/906
907: デフォルトの名無しさん [sage] 02/11/16 01:22 >>906 みんな同期問題の方に目がいっちゃってたね。 http://toro.5ch.net/test/read.cgi/tech/997345868/907
908: デフォルトの名無しさん [sage] 02/11/16 01:24 >>902 getって削除された要素を飛ばして次の要素を返すんじゃないか？ あと、removeが値を返してるよ。 >>905 その参照を増やす手段がgetなんだけど… http://toro.5ch.net/test/read.cgi/tech/997345868/908
909: デフォルトの名無しさん [sage] 02/11/16 01:27 スレッドだけに限らず、とにかく「何ヶ所から指されてるか」 をちゃんと保持しないと。変数に代入したらちゃんと参照カウント 増やせ。 http://toro.5ch.net/test/read.cgi/tech/997345868/909
910: デフォルトの名無しさん [sage] 02/11/16 01:28 だから、参照カウント法はマルチスレッドにむちゃくちゃ不向き なんだから、まともなGC使えってば... http://toro.5ch.net/test/read.cgi/tech/997345868/910
911: デフォルトの名無しさん [sage] 02/11/16 01:35 >>908 スレッド A からスレッド B に参照を代入しようとしている。同時にスレッド C が 参照を開放しようとしている。 最初の時点で参照を持っているのは A と C だから参照数は 2、C がカウントダウン したところで参照数は 1、そのあと B に代入されてカウントは 2 になる。 これのどこに参照数 0 になる要素があるか答えよ (同期化は当然行っている とする)。 # と断言して俺が間違ってたら恥ずかしいわけだが… http://toro.5ch.net/test/read.cgi/tech/997345868/911
912: デフォルトの名無しさん [sage] 02/11/16 01:38 単なる論理バグで 100 以上引っ張った悪寒 http://toro.5ch.net/test/read.cgi/tech/997345868/912
913: デフォルトの名無しさん [sage] 02/11/16 01:43 論理バグというより、勉強不足でしょ。 http://toro.5ch.net/test/read.cgi/tech/997345868/913
914: デフォルトの名無しさん [sage] 02/11/16 01:46 >>911 スレッドの数だけ数えりゃ良いわけじゃないって言うとるに。 ヒープ上のデータ(たとえばリスト)から参照されてて、 そのリストを指しているのはスレッドDだけだったとする。 あんたの数え方だと、スレッドAとBが参照を離したら、 リストから指されてるのに解放されちゃうよ。 また、同じスレッドの中でメソッド呼び出しに参照を渡した とする。この時にも参照を増やさないと。呼び出された先で 参照が不要になったからって勝手にカウントダウンしたら 呼び出し元が困るだろ。 http://toro.5ch.net/test/read.cgi/tech/997345868/914
915: デフォルトの名無しさん [sage] 02/11/16 01:48 >>910 でも、C++みたいな言語でGCも怖い気がする。 GCのバグ云々じゃなく、相当気をつけて使わないと、GCと 例外機構やデストラクタが衝突してあぼーん、になりそうで 不安。Cの方がまだしも、処理系の動きが見えやすいだけ、 楽な気がする。 http://toro.5ch.net/test/read.cgi/tech/997345868/915
916: デフォルトの名無しさん [sage] 02/11/16 01:51 >>914 後半は普通につかってりゃありえんだろ http://toro.5ch.net/test/read.cgi/tech/997345868/916
917: デフォルトの名無しさん [sage] 02/11/16 01:52 >>914 >あんたの数え方だと、スレッドAとBが参照を離したら、 >リストから指されてるのに解放されちゃうよ。 914をどう読むとそういう数え方になるんだ？ >また、同じスレッドの中でメソッド呼び出しに参照を渡した >とする。この時にも参照を増やさないと。呼び出された先で >参照が不要になったからって勝手にカウントダウンしたら >呼び出し元が困るだろ。 それは弱い参照にするかどうかだよね。呼び出された先が、 どこにもその参照を突っ込まないで、カウントを変えないまま リターンすれば問題ないわけで。 参照カウントの有難味は無くなるけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/917
918: デフォルトの名無しさん [sage] 02/11/16 01:56 >>908 いや、index が識別子なのか単なる順序値なのかわからんし、 一応こうしといた。 remove は中途半端になっちまった。引数の型も抜けてるし。 中で release する場合と、オブジェクトを返して外で release する 場合と考えてた。 http://toro.5ch.net/test/read.cgi/tech/997345868/918
919: デフォルトの名無しさん [sage] 02/11/16 01:56 いくつの「スレッドが」参照してるかなんていう 数え方をするから間違える。 シングルスレッドでも参照カウントはちゃんと増減させるだろ？ とにかく「何ヶ所から指されているか」を正しく参照カウント に反映させておかないと。 メソッド呼び出しではたしかに人間が推論して最適化すること はあるね。間違いのもとだけど。 http://toro.5ch.net/test/read.cgi/tech/997345868/919
920: デフォルトの名無しさん [sage] 02/11/16 01:59 >>914 スレッド D が持つリストからも参照されてるなら初期状態での参照数は 3 だろ。 逝っておくがいくつのスレッドで共有されているかをカウントしているという意味 ではないぞ。 ただ循環参照になってるとどこからも使われてないのに参照数が残ってしまう だろうな。単純な参照カウントの弱いところだ。 http://toro.5ch.net/test/read.cgi/tech/997345868/920
921: 767=793=902 [sage] 02/11/16 02:10 で、736 はどうした。問題は解決したか？ とりあえずリスト全体ロックは回避できたんだから、これくらい(複数のロックを使う)で 手を打つのがよいと思うのだが。 あとは、refcount が 0 になってもその場では削除せず、後で回収するくらいしか 無いと思う。もちろん回収の時は、全スレッドを安全な場所で停止させる必要があるが。 っつーかもっといい手があるのかどうか俺も知りたい。 http://toro.5ch.net/test/read.cgi/tech/997345868/921
922: デフォルトの名無しさん [sage] 02/11/16 02:33 ＯＫ 埋め立て成功。 ∧＿∧ ∧＿∧ （´<_｀ ） （ ´_ゝ`） / ⌒i さすがだな兄者。 ／ ＼ | | / /￣￣￣￣/ | ＿_(__ﾆつ/ FIVA / .| .|＿＿＿＿ ＼/＿＿＿＿/ （u ⊃ http://toro.5ch.net/test/read.cgi/tech/997345868/922
923: 772 [sage] 02/11/16 02:54 ＃うわあ。見ないでいたらこんな事態に… ＃なんか終息しかけてますけど、まあ話題としては面白いのでいいけど。 ええと、>>788が重要な指摘だと思いますよ。 >>786の「実際には目的のデータであることを確認後」 この確認はどういうコードで行っているのですか？ ぱっと思いつくコードは例えばこうなんですけど。 //目的のデータであることを確認 O3 = O1 ; //ここで既に参照カウントが上がってる！ if (! IsWanted(O3)) { //O3生成の瞬間にO1が破棄されているとO3に新規データが入っている //エラー処理 } O2 = O1 ; //既にO3があるのでO2は要らないけど安全にコピーできる。 なんか私大間違いしてます？ http://toro.5ch.net/test/read.cgi/tech/997345868/923
924: デフォルトの名無しさん [] 02/11/16 05:16 しかし良く考えてみると、リスト全体にロックしないと removeはやっぱり出来ないんじゃないかなー。 単方向リストでも、双方向リストでも、配列+ホールでも… 少なくとも「ｎ番目getする｣という操作は正しく動かないだろう。 「キーｋを持つ要素をgetする」ときも、一部だけロックで出来る？ http://toro.5ch.net/test/read.cgi/tech/997345868/924
925: デフォルトの名無しさん [sage] 02/11/16 05:22 素直にJava使え。 http://toro.5ch.net/test/read.cgi/tech/997345868/925
926: デフォルトの名無しさん [sage] 02/11/16 07:53 なんでこんなくだらん事で話を引っ張ってるの？ ＞ >>736 http://toro.5ch.net/test/read.cgi/tech/997345868/926
927: デフォルトの名無しさん [sage] 02/11/16 09:06 http://www15.big.or.jp/~kaini/image/img-box/img20021111111348.jpg まぁこれでも見てﾏﾀｰﾘしる http://toro.5ch.net/test/read.cgi/tech/997345868/927
928: デフォルトの名無しさん [sage] 02/11/16 12:13 Javaでもコレクションクラスのthread safetyについて考慮してるのは jdk1.2以降ですな。 http://toro.5ch.net/test/read.cgi/tech/997345868/928
929: デフォルトの名無しさん [sage] 02/11/16 12:28 >>928 thread safety についてというか、1.1 までのコレクションは莫迦でも使えるように 何でもかんでも同期化してただけ。 http://toro.5ch.net/test/read.cgi/tech/997345868/929
930: デフォルトの名無しさん [sage] 02/11/16 12:40 1.4の日本語ヘルプ >ConcurrentModificationException >... >たとえば、あるスレッドが Collection で繰り返し処理を行なっている間に、 >別のスレッドがその Collection を変更することは通常許可されません。 通常ダメなんだとさ。 http://toro.5ch.net/test/read.cgi/tech/997345868/930
931: デフォルトの名無しさん [sage] 02/11/16 13:41 この争いに参加しなかった俺は自制心の持ち主 http://toro.5ch.net/test/read.cgi/tech/997345868/931
932: デフォルトの名無しさん [sage] 02/11/16 14:50 レベル低いだけだろ?(W http://toro.5ch.net/test/read.cgi/tech/997345868/932
933: デフォルトの名無しさん [sage] 02/11/16 15:06 >>929 じゃあ、いまでもVectorとか使ってるばかには使わせといた方がいいんですか？ http://toro.5ch.net/test/read.cgi/tech/997345868/933
934: デフォルトの名無しさん [sage] 02/11/16 15:42 Javaなら少なくともreference countで悩む必要はないね。 http://toro.5ch.net/test/read.cgi/tech/997345868/934
935: デフォルトの名無しさん [sage] 02/11/16 17:07 >>934 でも、たま〜に使いたくなることあるなぁ。。。 http://toro.5ch.net/test/read.cgi/tech/997345868/935
936: デフォルトの名無しさん [sage] 02/11/16 18:35 参照カウンタの使い方程度も分からないバカはJavaがお似合いだね http://toro.5ch.net/test/read.cgi/tech/997345868/936
937: デフォルトの名無しさん [sage] 02/11/16 22:23 736 はどうしたのよ？ 散々人を見下した発言を繰り返した割には、反論できずにだんまりかよ ヘタレやの、おまえ http://toro.5ch.net/test/read.cgi/tech/997345868/937
938: デフォルトの名無しさん [sage] 02/11/16 22:31 >>937 もういいよ・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/938
939: デフォルトの名無しさん [] 02/11/16 23:57 真理を見通す目を使ってこのスレを覗いてみた。そこに見えたものは・・・ 938 名前：736 投稿日：02/11/16 22:31 >>937 もういいよ・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/939
940: デフォルトの名無しさん [sage] 02/11/17 00:04 736マジ死亡!? もっと踊ってくれよ http://toro.5ch.net/test/read.cgi/tech/997345868/940
941: 772 [sage] 02/11/17 00:29 >>923 あ、違った。O1がBスレッドにあるという時点で 既に参照カウントがアガってなきゃいかんのか。 鬱だ…。 DataType O1; hr = pDataList->GetItem(index, &O1) ; if (FAILED(hr)) { /* エラー*/ } if (IsWanted(O1) とか。ふむ。確かにリスト側で排他したくなるし、 同時に他スレッドで削除されてると面倒。やっと分かった。 http://toro.5ch.net/test/read.cgi/tech/997345868/941
942: 767=793=902=918=921 [sage] 02/11/17 02:31 >>941 参照を得る/切るタイミングでアトミックにカウントが上がる/下がる必要が あるからなぁ。 そうでないと、無効なオブジェクトを参照してしまう。 ならば、参照カウントが 0 でも有効な(というより、無効かどうか判別できる) ものを作るのも一つの手だな。 bool Object::ref(){ bool valid = false; cs_.enter(); if(refCount_ > 0){ refCount_++; valid = true; } cs_.leave(); return result; } void Object::release(){ cs_.enter(); if(refCount_ > 0){ refCount_--; if(refCount_ == 0){ garbages__.add(this); } } cs_leave(); } で、安全なタイミングで(ってそれが一番むずい気も)garbages__(グローバル変数) の要素を delete してやると。 http://toro.5ch.net/test/read.cgi/tech/997345868/942
943: 942 [sage] 02/11/17 02:32 # 続き。改行が多すぎるって言われちまった。 あるいは、Object ではなく、SharedPtr みたいな入れ物でこれをやっても良い。 SharedPtr のフィールドは Object* を格納する ptr_ と refCount_。refCount_ が 0 になったときに delete ptr_ するけど、 SharedPtr 自体は無効な状態で 残り、garbages__ に入る。 コメントくれ 736。もしくは偉い人。 http://toro.5ch.net/test/read.cgi/tech/997345868/943
944: 942 [sage] 02/11/17 02:40 >>942 ああ。result 返してるよ。ref の最後は return valid; ね。 コンパイルくらいは通すか... http://toro.5ch.net/test/read.cgi/tech/997345868/944
945: デフォルトの名無しさん [sage] 02/11/17 04:18 もまいら別スレ立ててそっち逝け http://toro.5ch.net/test/read.cgi/tech/997345868/945
946: デフォルトの名無しさん [sage] 02/11/17 08:10 >>943 736でも偉い人でもないが… ref()がfalseを返したら、いったい何をすればよいんだ？ そもそも、release()で参照が0になるということは、release()を呼んだスレッド 以外からの参照はないはずなのに、他からref()が呼ばれるのがおかしいってば。 リストのgetとremoveが排他制御をちゃんとやれば、そういうことは起きないだろ？ getがロックを離す前にはrefが済んでいる。あるいは、removeが先なら、 参照が他のスレッドに渡ることはない。 http://toro.5ch.net/test/read.cgi/tech/997345868/946
947: デフォルトの名無しさん [] 02/11/17 16:21 やっぱり、どう考えてもリスト全体をロックするより無いなー。 http://toro.5ch.net/test/read.cgi/tech/997345868/947
948: デフォルトの名無しさん [sage] 02/11/17 22:17 Javaを使えば簡単に解決する低次元な問題に 一生悩みつづけるC++プログラマのスレはここですか？ http://toro.5ch.net/test/read.cgi/tech/997345868/948
949: デフォルトの名無しさん [sage] 02/11/17 22:24 二日留守にしてたからとっくに終ってるかと思えば、まだ続いてたのかよ。こ の736祭は。 http://toro.5ch.net/test/read.cgi/tech/997345868/949
950: デフォルトの名無しさん [sage] 02/11/17 22:31 >>948 >>930 http://toro.5ch.net/test/read.cgi/tech/997345868/950
951: デフォルトの名無しさん [sage] 02/11/17 22:41 >>948 うん だからオマエには関係ないんよ どっか逝け、二度と来んな http://toro.5ch.net/test/read.cgi/tech/997345868/951
952: 942 [sage] 02/11/17 22:45 >>946 いやだから。 List で排他制御をかけずに安全な方法があるかを探してる。 ってあまりやると今度は俺が煽られるかな。 http://toro.5ch.net/test/read.cgi/tech/997345868/952
953: デフォルトの名無しさん [sage] 02/11/18 00:50 >>952 特殊な場合はあるかもしれんが、一般的なリストのセマンティクスを ロックなしで一貫性を持って実現するのは無理だろう。 たとえば 「n番目を取り出す｣→他のスレッドが先頭を削除したら、戻ったときには正しくない値を返してしまう。 「データｘを含む最初の要素を取り出す｣→探索中に他のスレッドが先頭にｘを 付け加えたら… http://toro.5ch.net/test/read.cgi/tech/997345868/953
954: 942 [sage] 02/11/18 01:19 >>953 その特殊な場合が知りたい。 そのために、902 の List::remove では、items_[index] = NULL をもって 要素削除としてる。 いや、現実問題、こんなことしてたら、List も Object も、使う側に 知識を要求する、やっかいなクラスになるとは思う。 ただ、そうすることによってパフォーマンスが得られるなら、 それが有効な選択肢になる場合もある。 ってことで、無理問答みたいなことを続けてるわけだ。 っていうか 736 が続けてくれよこれ。 http://toro.5ch.net/test/read.cgi/tech/997345868/954
955: デフォルトの名無しさん [sage] 02/11/18 10:58 あのさぁ、参照カウントの時に出てきた↓を見てみたんだけど、 http://www.gotw.ca/gotw/045.htm void String::AboutToModify(size_t n, bool bMarkUnshareable /* = false */) int refs = IntAtomicGet( data_->refs ); if( refs > 1 && refs != Unshareable ) { StringBuf* newdata = new StringBuf( *data_, n ); if( IntAtomicDecrement( data_->refs ) < 1 ) { delete newdata; // just in case two threads } // are trying this at once else { // now all the real work is data_ = newdata; // done, so take ownership } } else { data_->Reserve( n ); } data_->refs = bMarkUnshareable ? Unshareable : 1; } の、delete newdataって間違いじゃない? http://toro.5ch.net/test/read.cgi/tech/997345868/955
956: 955 [sage] 02/11/18 11:25 複数のスレッド(それぞれが参照を持つ)が同時にAboutToModifyを呼び出すと、 それぞれが共有を解除して、独自にデータを持つわけだが、その内の一つは data_->refs が0になるから、元の共有していたdata_の指す先か、newdataの 一方を開放する必要がある。 というのは判るんだけど、AbountToModifyは共有解除と共にsize_t nに データ領域のサイズを拡張しなきゃならんのに、delete newdataでは data_の指す先の領域のサイズはsize_t nだけあるとは限らなくない? ここは、単純に if( IntAtomicDecrement( data_->refs ) < 1 ) { delete data_; // just in case two threads } data_ = newdata; // done, so take ownership じゃないかと思うんだが… http://toro.5ch.net/test/read.cgi/tech/997345868/956
957: 名無しさん＠カラアゲうまうま [sage] 02/11/18 14:10 あるいはこうか? if( IntAtomicDecrement( data_->refs ) < 1 ) { delete newdata; // just in case two threads data_->Reserve( n ); } // are trying this at once http://toro.5ch.net/test/read.cgi/tech/997345868/957
958: 955 [sage] 02/11/18 16:22 ですな。 でも、既にnewdataはサイズn以上で領域確保しているので、 data_を破棄する方が良いかと。 誰も、反論が無いところを見ると、やっぱり間違いと言う事でよろしいか? http://toro.5ch.net/test/read.cgi/tech/997345868/958
959: デフォルトの名無しさん [sage] 02/11/18 16:33 パフォーマンスを得るためならreference count法なんて 使っちゃいかんと思うが... http://toro.5ch.net/test/read.cgi/tech/997345868/959
960: 名無しさん＠カラアゲうまうま [sage] 02/11/18 17:15 >>958 いいんじゃん。 ところで、次スレって立てんの? http://toro.5ch.net/test/read.cgi/tech/997345868/960
961: デフォルトの名無しさん [sage] 02/11/18 18:59 >959 別にリファレンスカウントでアロケーション回数を少なくしてパフォーマンスを稼ごう という事ではなくて、そもそも大域的なデータをマルチスレッドで使う時には意味無いかな? http://toro.5ch.net/test/read.cgi/tech/997345868/961
962: デフォルトの名無しさん [sage] 02/11/19 00:11 >>960 マルチスレッドプログラミングの苦労はすべて、 C++を使う事が原因だと結論が出たので、 次スレは不要でしょう。 http://toro.5ch.net/test/read.cgi/tech/997345868/962
963: デフォルトの名無しさん [sage] 02/11/19 00:58 たてますよー http://toro.5ch.net/test/read.cgi/tech/997345868/963
964: 963 [sage] 02/11/19 01:02 載せるようなリンク先がねえよ... http://toro.5ch.net/test/read.cgi/tech/997345868/964
965: デフォルトの名無しさん [sage] 02/11/19 01:16 >>962 どっちかというと、不要なのはオマエだな http://toro.5ch.net/test/read.cgi/tech/997345868/965
966: 次スレの逝ってよしの１ [sage] 02/11/19 01:43 次スレ立てました http://pc3.2ch.net/test/read.cgi/tech/1037636153/ 間違えて３つも立ててしまった・・・ 決してマルチスレッドとかけたわけではありませぬ・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/966
967: デフォルトの名無しさん [] 02/11/19 02:07 じゃあ1000取りでもはじめるか http://toro.5ch.net/test/read.cgi/tech/997345868/967
968: デフォルトの名無しさん [sage] 02/11/19 02:07 どれが本スレなんだ・・・。 次スレには全部重複ごめん、次スレはこちら、と書いてあり リンクをたどると無限ループするんだが・・・。 http://toro.5ch.net/test/read.cgi/tech/997345868/968
969: デフォルトの名無しさん [sage] 02/11/19 02:14 >>968 削除依頼板に書いてあるとおりです http://toro.5ch.net/test/read.cgi/tech/997345868/969
970: デフォルトの名無しさん [sage] 02/11/19 10:15 スレ立てもマルチスレッドでやって、排他制御に失敗したのはこのスレですか? http://toro.5ch.net/test/read.cgi/tech/997345868/970
971: デフォルトの名無しさん [sage] 02/11/19 10:20 ここの奴らの話は信用ならねーな http://toro.5ch.net/test/read.cgi/tech/997345868/971
972: デフォルトの名無しさん [sage] 02/11/19 13:25 つーか「間違えて」3つも立てられるはずないだろ。 明らかに故意に串を差し替えるとか回線を繋ぎ替えるかして 立てたはずだ。 市ねよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/972
973: デフォルトの名無しさん [sage] 02/11/19 13:26 >>968 素朴な参照カウントモデルは循環参照があると 役に立たないのです http://toro.5ch.net/test/read.cgi/tech/997345868/973
974: 次スレの逝ってよしの１ [sage] 02/11/19 22:59 >>972 いえ、それが同じアドレスから３連発したのです 一度目はコネクションタイムアウト 二度目は３０秒ぐらいでこちらから停止 三度目で成功 で、気づいたら３つ立ってました（；＿；） 一回目の段階で、しばらく待って、スレ一覧をチェックすればよかったんですね。 しばらくスレ立てはやめときます・・・ http://toro.5ch.net/test/read.cgi/tech/997345868/974
975: デフォルトの名無しさん [sage] 02/11/20 00:28 2ch の調子が悪くてスレ立ての重複が頻発しているらしいよ。 http://toro.5ch.net/test/read.cgi/tech/997345868/975
976: デフォルトの名無しさん [sage] 02/11/20 11:59 >973 > 素朴な参照カウントモデルは循環参照があると うん、それで？ 参照カウントを使って、どんな場合にも使えるクラスを設計しようとしてるならともかく、 循環参照が発生しないデータモデルで使用する場合には、何の意味も無いな。 >972 スレが３つ立ったからって、そんなに迷惑被ったのかヨ？ 引きこもりは、攻撃性が強くて困るな。 http://toro.5ch.net/test/read.cgi/tech/997345868/976
977: デフォルトの名無しさん [sage] 02/11/20 12:50 >>976 「リンクをたどると無限ループ」に引っ掛けたネタに マジレスされても困るのだが http://toro.5ch.net/test/read.cgi/tech/997345868/977
978: デフォルトの名無しさん [sage] 02/11/20 13:47 >>973 ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ >>976 ﾈﾀﾉｶｲｾﾂｶｺﾜﾙｲ http://toro.5ch.net/test/read.cgi/tech/997345868/978
979: デフォルトの名無しさん [sage] 02/11/20 13:48 >>978 >>976 -> >>977 ﾈﾀﾉﾃｲｾｲｶｺﾜﾙｲ ｲｯﾃｷﾏｽ... http://toro.5ch.net/test/read.cgi/tech/997345868/979
980: デフォルトの名無しさん [sage] 02/11/24 17:19 誰も居ない・・・ ？？？？するならイマノウチ http://toro.5ch.net/test/read.cgi/tech/997345868/980
981: デフォルトの名無しさん [sage] 02/11/24 18:11 ？？？？ http://toro.5ch.net/test/read.cgi/tech/997345868/981
982: デフォルトの名無しさん [sage] 02/11/24 20:18 ？？？？ http://toro.5ch.net/test/read.cgi/tech/997345868/982
983: デフォルトの名無しさん [sage] 02/11/24 21:19 ？？？？ http://toro.5ch.net/test/read.cgi/tech/997345868/983
984: デフォルトの名無しさん [sage] 02/11/24 22:11 ？？？？ http://toro.5ch.net/test/read.cgi/tech/997345868/984
985: デフォルトの名無しさん [sage] 02/11/24 23:47 ぬるぽー！！ ぬるぽぬるぽぬるぽぬるぽぬるぽ ぬ る ぽ ー っ ！ ！ ！ http://toro.5ch.net/test/read.cgi/tech/997345868/985
986: デフォルトの名無しさん [sage] 02/11/25 00:38 ？？？？ http://toro.5ch.net/test/read.cgi/tech/997345868/986
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.127s*