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

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

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

811(1): 736 02/11/15 11:23 AAS
じゃあ、COMもおかしいのか?

812(3): 02/11/15 11:49 AAS
>>809
「どこにでもある」が「おかしくない」の理由には全然ならない事に気付け。
つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな
サンプルに見舞われてるんだな。

>>811
おかしいのは COM を把握してないのにわかったつもりになってるあんたの頭。

つーか、教えを乞う立場だったら、もっと謙虚になれ。
主観を捨てろ。
答えへのポインタはもう不必要なほど出ているのに、あんたはそれを全部捨てている。

813(2): 736 02/11/15 12:24 AAS
>812
>つーか、教えを乞う立場だったら、もっと謙虚になれ。

共有しているオブジェクトの集合に丸ごとロックかけずに、
各オブジェクトの参照カウントだけで済むかがポイントなのに、

参照カウントのインクリメント不足だとか、
COMを知ってればとか、
おんなじ事おんなじ事おんなじ事おんなじ事ばかーーーり。
しつこつしつこくしつこーーーーく同じこと繰り返す粘着が多くてウンザリ。

getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。
参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。
じゃあ、参照を手に入れる処理を書いてみろというと、とたんに逃げ出す。
どうしてポイントがずれた香ばしい奴が多いのか。

814: 736 02/11/15 12:26 AAS
>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);}
しか使われないと思うが（Ｗ

815: [ sage ] 02/11/15 12:37 AAS
736の、これまでの発言で推測できること。
1.listでCOM objectを束ねているらしい
2.list内のあるCOM objectに対して、
　releaseとrefが(release->refの順で)発生して死ぬようだ
3.list全体に対するlockはかけたくないらしい
　(listが持つCOM objectに対する個々のロックは可能みたい？)

736の発言だけで、この問題がわかるかってーの。
それを736の時点で言えば、まだ混乱は少なかっただろうに。
変に情報を出し惜しむから、おなじ事をしつこく何度も
言われる羽目になる。おまけに自分のことを棚に上げて
しつこいとか、ポイントがずれてるとか、香ばしいとか言うし。

816: 736 02/11/15 12:40 AAS
それで？

817: [ sage ] 02/11/15 12:42 AAS
で、815であげた推測は正しいのかい？
というか、コードだせ、コード。問題の起こる、
必要最小限の、736の書いたコードを。

818: 736 02/11/15 12:44 AAS
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
「別のスレッドが使うためにコピーを作る」ときに
「インスタンスの元のホルダーがオブジェクトを破棄」しちゃおかしいだろ。
「別スレッドに渡す」ときにコピーができるもんだろ、ふつー。

819: 736 02/11/15 12:44 AAS
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の発行の仕方がオカシイんや。

820: 736 02/11/15 12:45 AAS
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が解放し
てしまうというのはバグ。

821: 02/11/15 12:48 AAS
736 荒らしｹﾃｰｲ
（いや、元々そうだったという説もあるが・・・）

という訳で出て逝ってくれ。

822(1): 736 02/11/15 12:51 AAS
君らのしつこさを確認させてやっただけだよ

823: [ sage ] 02/11/15 12:53 AAS
( ´，_ゝ｀)ﾌﾟッ

824: 736 02/11/15 12:58 AAS
結局誰も判らんのか。それならそう言えよ無能者ども。

825: 02/11/15 13:00 AAS
>>822
あのさあ、
しつこいのは　お　ま　え　（ｗ
消えろ

826(1): 02/11/15 13:03 AAS
>>813
> 共有しているオブジェクトの集合に丸ごとロックかけずに、
> 各オブジェクトの参照カウントだけで済むかがポイントなのに、
参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
してないのはシングルスレッドを前提にしてる場合だけ。
わかった?

> 参照カウントのインクリメント不足だとか、
> COMを知ってればとか、
> おんなじ事おんなじ事おんなじ事おんなじ事ばかーーーり。
> しつこつしつこくしつこーーーーく同じこと繰り返す粘着が多くてウンザリ。
なんでおんなじ事をこんなにしつこく説明してやらなきゃならんのか…。

> getはアトミックだとか…あのなあ、それ自体はアトミックでもremoveとgetを同時に呼ぶことは出来るんだよ。
> 参照を持っているならとか…あのなあ、その参照を受け取るのがgetだろ。共有オブジェクトのgetなんだよヴォケ。
そのアトミックなgetにカウントのインクリメントを含めてないからバグって
んだろが。

827(1): 736 02/11/15 13:07 AAS
まだ言ってるのか。
>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
>してないのはシングルスレッドを前提にしてる場合だけ。
>わかった?

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);
}
としたら満足か？（Ｗ

828: 736 02/11/15 13:09 AAS
>826
おまえ、InterlockXXってなんのためにあるのか知らんだろ。
知らない奴に限って、無駄なレスを返しやがる。

829: 02/11/15 13:12 AAS
としたら満足か、って・・・
一体何の為にここに質問に来たんだ？

830(1): 02/11/15 13:17 AAS
736の無能っぷりをさらけ出すスレはここですか？

>>837
>EnterCriticalSection(&m_mutex);
>　InterlockedIncrement(&m_ref);　
>LeaveCriticalSection(&m_mutex);

クリティカルセクション張ってるんだから、
インターロック不要なんだけど。

>EnterCriticalSection(&m_mutex);
>　if (InterlockedDecrement(&m_ref) == 0) {
>　　delete this;
>　}
>LeaveCriticalSection(&m_mutex);

自分で書いてておかしいと思わないのかなあ・・

831: 736 02/11/15 13:21 AAS
>>836

あのなあ、

>>参照カウントのインクリメントにはロックは*原理的に*必要不可欠。
>>してないのはシングルスレッドを前提にしてる場合だけ。
>>わかった?

というのは読めないのか。お前は、自然言語にたいする理解力は０だな。
ロックかけなきゃだめだと言ってるやつがいるから、ロックしたまで。
なーんの解決にもならんし、もともと、Interlockしてるから不要なんだがな。

832: 736 02/11/15 13:21 AAS
>830
だわ

833: 736 02/11/15 13:23 AAS
で？８２６も逃げたのか。全く都合が悪くなると逃げて…自分の発言に席にもてよ。
どうせ、別人のフリしてまた別の事言い出すんだろうが

834: 736 02/11/15 13:26 AAS
ん？deleteまではロックしなきゃダメかな。
まあ、どのみちref()でロック獲得したときに、解放済みというのは避けられんが。

835: 02/11/15 13:28 AAS
>>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のほうで排他処理をするのが自明の理。

836(1): 736 02/11/15 13:34 AAS
やっぱり、List::get()でリストの検索処理が丸ごとロックするしかないのか。

837(1): 02/11/15 13:40 AAS
(´-`).｡ｏＯ(100レスかけてようやく染み込んだのか)

838(1): 736 02/11/15 13:49 AAS
それ以外に無いのか聞いてんだが。
ここのいる連中じゃ無理のようだ（Ｗ

839(1): 736 02/11/15 13:53 AAS
>812
>「どこにでもある」が「おかしくない」の理由には全然ならない事に気付け。
>つーか、そんなのそうそう転がってないはずなんだが、あんたよっぽどクソな
>サンプルに見舞われてるんだな。

８１２も逃げたようだな。逃げ足の速い連中だ。

840(1): 02/11/15 14:07 AAS
>>838
> それ以外に無いのか聞いてんだが。
散々いわれてんのに。>>762とか>>785とか。
大体間接的に渡すって話自体>>789くらいでいきなりだし。

>>839
> ８１２も逃げたようだな。逃げ足の速い連中だ。
いつまでも君の相手してらんないしね。
漏れもそろそろ出かけなきゃならないんでバイバイ。

841: 02/11/15 14:27 AAS
winでのTerminateThreadと同じような
関数はunixにありますか？

842: 02/11/15 14:38 AAS
pthreadならpthread_cancel()かな。TerminateThreadと違って必ずしも即座に
終了するわけじゃないけど。

843: 02/11/15 14:44 AAS
教えて下さい。
pthread_cancel()を実行すると
実行されたスレッドの終了はいつになるのですか？

844: 02/11/15 14:47 AAS
実行してみればわかる

845: 736 02/11/15 15:06 AAS
>840
またバカが湧いてきた。

>散々いわれてんのに。>>762とか>>785とか。
>762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？
リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。
君のような厨には理解で菌だろうがな。

>大体間接的に渡すって話自体>>789くらいでいきなりだし。
間接的?ハァ?頭大丈夫?

785は俺だ。
たくっ。ろくに読まないでレスするアホウは書くなっつの。

>いつまでも君の相手してらんないしね。
>漏れもそろそろ出かけなきゃならないんでバイバイ。

いや、君みたいなアホウに相手してくれとは言ってないから（Ｗ
お呼びでないの（Ｗつか出てくんなっての

大体、レスして何か言われたら自分が誰かわかるように名前に番号入れるもんだろ。
言いっぱなしで自己満足してる厨が多すぎ。

846: 736 02/11/15 15:16 AAS
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);
}

って書いてるのかな。馬鹿だなー。
こんな事言ってる奴が多いのは　オ　ド　ロ　キ。
もはや都市伝説だな。

847: 736 02/11/15 15:17 AAS
おっ！
830が、慌ててネットで調べ始めた。まあ、自分の馬鹿さ加減を思い知れ。

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

849(1): 02/11/15 15:34 AAS
void ref() {
　InterlockedIncrement(&m_ref);　// A
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　// B
　　delete this;
　}
}
B のタイミングで A が呼ばれた場合。

850(1): 02/11/15 15:45 AAS
void ref() {
　InterlockedIncrement(&m_ref);　// A
}
void release() {
　if (InterlockedDecrement(&m_ref) == 0) {
　　delete this;
　　// C
　}
}
C のタイミングで A が呼ばれた場合。

しかし、危険性において 846 のコードは結局 848 と変わらないな。

851: 736 02/11/15 15:48 AAS
おいおい、本当にのこのこ出てきたよ。恥ずかしい奴だ。

852: 736 02/11/15 15:50 AAS
>しかし、危険性において 846 のコードは結局 848 と変わらないな。
説明してみろよ。わくわく。
Bのところに行くのは、どういう場合さ?

853: 02/11/15 16:01 AAS
>８４９
馬鹿です。

854: 02/11/15 16:01 AAS
晒しage

855(1): [ sage ] 02/11/15 16:02 AAS
＞>762は、各オブジェクト毎にロック掛けるって意味ならロックが多量に必要だし、リストにはロック掛けないのか？
＞リストにロックかけるんだったら、各オブジェクト毎に掛ける必要なし。
＞君のような厨には理解で菌だろうがな。

つか、762の時点では、そもそもリストが使われていることが
説明されていないわけで、762の時点で「リストにもロックかけろよ」
と言えるなら、そいつは神

856: 736 02/11/15 16:03 AAS
あげてねーじゃん

857: 736 02/11/15 16:04 AAS
>855
リストである必要なし。
グローバル変数など共有してれば同じ。
この場合動的じゃなきゃ意味無いが。

858: [ sage ] 02/11/15 16:08 AAS
何がおなじなんだか、、、

859(1): 02/11/15 16:10 AAS
思うんだが、ref() を bool 型にして、呼び出し側で false を受け取ったら取得を諦める
ようにはできないのか？

bool m_sw1st; // コンストラクタで true に
bool ref() {
　bool ret = true;
　EnterCriticalSection(&m_cs);
　if(!m_ref)
　{
　　if(m_sw1st)
　　　m_sw1st = false;
　　else
　　　ret = false;
　}
　if(ret)
　　++m_ref;
　LeaveCriticalSection(&m_cs);
　return ret;
}
void release() {
　EnterCriticalSection(&m_cs);
　if (--m_ref) == 0) {
　　delete this;
　}
　LeaveCriticalSection(&m_cs);
}

参照カウンタが 1 始まりなら m_sw1st は要らないけど。

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

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

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

ぬこの手ぬこTOP 1.601s*