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

736 はどうしたのよ？
散々人を見下した発言を繰り返した割には、反論できずにだんまりかよ
ヘタレやの、おまえ

>>937
もういいよ・・・

真理を見通す目を使ってこのスレを覗いてみた。そこに見えたものは・・・

938 名前：736 投稿日：02/11/16 22:31
>>937
もういいよ・・・

736マジ死亡!?
もっと踊ってくれよ

>>923
あ、違った。O1がBスレッドにあるという時点で
既に参照カウントがアガってなきゃいかんのか。
鬱だ…。

DataType O1;
hr = pDataList->GetItem(index, &O1) ;
if (FAILED(hr)) { /* エラー*/ }
if (IsWanted(O1)

とか。ふむ。確かにリスト側で排他したくなるし、
同時に他スレッドで削除されてると面倒。やっと分かった。

>>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 してやると。

# 続き。改行が多すぎるって言われちまった。

あるいは、Object ではなく、SharedPtr みたいな入れ物でこれをやっても良い。
SharedPtr のフィールドは Object* を格納する ptr_ と refCount_。refCount_ が
0 になったときに delete ptr_ するけど、 SharedPtr 自体は無効な状態で
残り、garbages__ に入る。

コメントくれ 736。もしくは偉い人。

>>942
ああ。result 返してるよ。ref の最後は return valid; ね。
コンパイルくらいは通すか...

もまいら別スレ立ててそっち逝け

>>943
736でも偉い人でもないが…

ref()がfalseを返したら、いったい何をすればよいんだ？

そもそも、release()で参照が0になるということは、release()を呼んだスレッド
以外からの参照はないはずなのに、他からref()が呼ばれるのがおかしいってば。

リストのgetとremoveが排他制御をちゃんとやれば、そういうことは起きないだろ？
getがロックを離す前にはrefが済んでいる。あるいは、removeが先なら、
参照が他のスレッドに渡ることはない。

やっぱり、どう考えてもリスト全体をロックするより無いなー。

Javaを使えば簡単に解決する低次元な問題に
一生悩みつづけるC++プログラマのスレはここですか？

二日留守にしてたからとっくに終ってるかと思えば、まだ続いてたのかよ。こ
の736祭は。

>>948
>>930

>>948
うん
だからオマエには関係ないんよ
どっか逝け、二度と来んな

>>946
いやだから。
List で排他制御をかけずに安全な方法があるかを探してる。

ってあまりやると今度は俺が煽られるかな。

>>952
特殊な場合はあるかもしれんが、一般的なリストのセマンティクスを
ロックなしで一貫性を持って実現するのは無理だろう。

たとえば
「n番目を取り出す｣→他のスレッドが先頭を削除したら、戻ったときには正しくない値を返してしまう。
「データｘを含む最初の要素を取り出す｣→探索中に他のスレッドが先頭にｘを
付け加えたら…

>>953
その特殊な場合が知りたい。
そのために、902 の List::remove では、items_[index] = NULL をもって
要素削除としてる。

いや、現実問題、こんなことしてたら、List も Object も、使う側に
知識を要求する、やっかいなクラスになるとは思う。

ただ、そうすることによってパフォーマンスが得られるなら、
それが有効な選択肢になる場合もある。
ってことで、無理問答みたいなことを続けてるわけだ。

っていうか 736 が続けてくれよこれ。

あのさぁ、参照カウントの時に出てきた↓を見てみたんだけど、
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って間違いじゃない?

複数のスレッド(それぞれが参照を持つ)が同時に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
じゃないかと思うんだが…

あるいはこうか?

　　if( IntAtomicDecrement( data_->refs ) < 1 ) {
　　　delete newdata; // just in case two threads
　　data_->Reserve( n );
　　} // are trying this at once

ですな。
でも、既にnewdataはサイズn以上で領域確保しているので、
data_を破棄する方が良いかと。

誰も、反論が無いところを見ると、やっぱり間違いと言う事でよろしいか?

パフォーマンスを得るためならreference count法なんて
使っちゃいかんと思うが...

>>958
いいんじゃん。

ところで、次スレって立てんの?

>959

別にリファレンスカウントでアロケーション回数を少なくしてパフォーマンスを稼ごう
という事ではなくて、そもそも大域的なデータをマルチスレッドで使う時には意味無いかな?

>>960
マルチスレッドプログラミングの苦労はすべて、
C++を使う事が原因だと結論が出たので、
次スレは不要でしょう。

たてますよー

載せるようなリンク先がねえよ...

>>962
どっちかというと、不要なのはオマエだな

次スレ立てました
http://pc3.2ch.net/test/read.cgi/tech/1037636153/

間違えて３つも立ててしまった・・・
決してマルチスレッドとかけたわけではありませぬ・・・

じゃあ1000取りでもはじめるか

どれが本スレなんだ・・・。
次スレには全部重複ごめん、次スレはこちら、と書いてあり
リンクをたどると無限ループするんだが・・・。

>>968
削除依頼板に書いてあるとおりです

スレ立てもマルチスレッドでやって、排他制御に失敗したのはこのスレですか?

ここの奴らの話は信用ならねーな

つーか「間違えて」3つも立てられるはずないだろ。
明らかに故意に串を差し替えるとか回線を繋ぎ替えるかして
立てたはずだ。
市ねよ。

>>968
素朴な参照カウントモデルは循環参照があると
役に立たないのです

>>972
いえ、それが同じアドレスから３連発したのです
一度目はコネクションタイムアウト
二度目は３０秒ぐらいでこちらから停止
三度目で成功
で、気づいたら３つ立ってました（；＿；）
一回目の段階で、しばらく待って、スレ一覧をチェックすればよかったんですね。

しばらくスレ立てはやめときます・・・

2ch の調子が悪くてスレ立ての重複が頻発しているらしいよ。

>973
> 素朴な参照カウントモデルは循環参照があると

うん、それで？
参照カウントを使って、どんな場合にも使えるクラスを設計しようとしてるならともかく、
循環参照が発生しないデータモデルで使用する場合には、何の意味も無いな。

>972
スレが３つ立ったからって、そんなに迷惑被ったのかヨ？
引きこもりは、攻撃性が強くて困るな。

>>976
「リンクをたどると無限ループ」に引っ掛けたネタに
マジレスされても困るのだが

>>973
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ
>>976
ﾈﾀﾉｶｲｾﾂｶｺﾜﾙｲ

>>978
>>976 -> >>977
ﾈﾀﾉﾃｲｾｲｶｺﾜﾙｲ
ｲｯﾃｷﾏｽ...

誰も居ない・・・
？？？？するならイマノウチ

？？？？

？？？？

？？？？

？？？？

ぬるぽー！！
ぬるぽぬるぽぬるぽぬるぽぬるぽ


　　　　　　ぬ　る　ぽ　ー　っ ！ ！ ！

？？？？