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