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

1 名前：デフォルトの名無しさん mailto:sage [2009/09/21(月) 17:19:27 ] マルチスレッドプログラミングについて語るスレ ■前スレ マルチスレッドプログラミング相談室 その７ pc12.2ch.net/test/read.cgi/tech/1215253576/ ■過去スレ その１ ttp://pc3.2ch.net/tech/kako/997/997345868.html その２ ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/ その３ ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/ その４ ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/ その５ ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/ その６ ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/ OS・言語・環境は問わないが、それゆえ明記すべし。 テンプレ 【ＯＳ】 【言語】 【実行環境】 【その他特記する事項】 138 名前： ◆0uxK91AxII mailto:sage [2009/10/02(金) 13:59:49 ] W2kSP4, Athlon 64 X2 3800+, VC6SP6+PP5, 最適化無し 50239 clocks at CriticalSection 49180 clocks at CAS 21132 clocks at CAS(lockプリフィックス無し) 32103 clocks at CAS(movでunlock) 139 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 14:24:08 ] >>136 それがメモリバリアの問題だっていう、そんなことわかってるよ。 そして、「一般的なmov」はメモリバリアの機能など持っていない事 さらに、「(次に書く)このスレで"一般に"用いられるCASという用語」はメモリバリアを持っているもね。 もちろん、CASというのがメモリバリアとは直接は関係ないってことだって充分知ってるよ。 (そうでなければ、lockなしのcmpxchgなんてもの出すわけ無いだろ) だけどこのスレで一般的にCASと言ったら 「アトミック操作で用いる事が可能なCAS」のことが普通だろうに。 140 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 14:28:11 ] 「一般的なmov」つまり、普通のロード/ストア操作はメモリバリアを持っていないのだから 普通のスピンロックの実装では、アンロック処理に movではなくメモリバリアを持ったTASやCASを使う。 (それらはロック獲得処理の段階で存在が示されている) だから「普通はmovでアンロック」などということは有りえない。 141 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 14:37:59 ] >>140は「教科書では」ね。 142 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 14:53:16 ] Windows Vista 64bit SP1, Core2DuoE6750, Microsoft Visual Studio 2008(VC Version 9.0.21022.8 RTM) /O2 /Ob2 /Oi /Ot (実行速度で最適化、インライン関数は展開可能な関数すべて展開) 101192 clocks at CriticalSection 67904 clocks at CAS 20424 clocks at CAS(lockプリフィックス無し) 88688 clocks at CAS(movでunlock) /Od /Ob1(最適化なし、インライン関数は展開しない) 108568 clocks at CriticalSection 99976 clocks at CAS 24184 clocks at CAS(lockプリフィックス無し) 65280 clocks at CAS(movでunlock) >>130の結果が謎すぎる 143 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 15:17:56 ] >>139 アトミック性とメモリバリアは別の概念だぞ。 CASがアトミックなのは当たり前であり、俺もそんなことに 文句をつけているわけじゃない。 x86におけるlockプレフィックスのないcmpxchgは SMP環境ではアトミック性が保証されないから (正しい意味での)CASとは言えない。 でも、>110で挙げたのは「アトミック性は保証されているが メモリバリア効果を持たないCAS」だ。 CASとは「あるメモリ位置に対する内容の取得・比較から代入までが アトミックに行える操作」であり、メモリバリア効果、つまり 「前後の命令との間でリオーダーを行わないという保証」は必須ではないと 俺は言っている。 # 実際に、C++0xのatomicライブラリではそのように定義されているし。 「普通のロード/ストア命令はメモリバリアを持たない」と言うのなら、 メモリバリアを持つロード/ストア命令を定義して、それを使えばいい。 何故わざわざCASやTASのような複雑な操作を持ち出す必要がある? ちなみに、x86のmov命令は(初期のバグ持ちプロセッサを除いて) デフォルトでreleaseメモリバリア効果を持っているぞ。 144 名前：デフォルトの名無しさん mailto:sage [2009/10/02(金) 15:36:13 ] はいはいごめんよ。 全部俺が悪かったよ。 145 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 09:36:48 ] ttp://d.hatena.ne.jp/bsdhouse/20090720/1248085754 ここが勉強になった。 146 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 10:16:52 ] ちらっと見ただけなんだけど、「volatile つけた変数に排他性は無いよ」 ってことをグダグダ言ってるみたいだけど、そんなの当たり前では？ 都市伝説もくそもねーよ 147 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 11:06:13 ] acquire/releaseバリヤって、 「そのスレッドでのメモリアクセスについて」限定？ ↑のスライドだと前後の命令を・・・となってるけど 148 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 11:36:54 ] 当たり前よ っつかどういう意味で聞いてる？ 149 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 11:37:10 ] 菊池バリヤー！ 150 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 16:40:11 ] 「バリア」って概念には 「メモリアクセスがコーダーが記述した”順”に実行されることが 保証される」っていう以上のものは含まれていない（例えばインク リメント操作がアトミックになることまでは保証されない）と認識し ているのですが。当たってます？ ネットに散らばっている情報にはブレがあると思えるし、正直、 勉強不足ではっきりと分からないところがあるので質問します。 151 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 18:09:38 ] >>150 それで正しい。 ちなみに、マルチスレッドの世界には「バリア同期」っていう全然別のものもあるので、 メモリバリアのことは「メモリフェンス」と呼ぶようにした方がいい。 152 名前：デフォルトの名無しさん [2009/10/03(土) 19:15:56 ] >>151 ありがとうございます。頭の中がすっきりしました。 153 名前： ◆0uxK91AxII mailto:sage [2009/10/03(土) 21:22:33 ] どうでも良い事だけど。 spinlockを奪い合った場合、 先に取ろうとした方が取れず、 後から取ろうとした方が取れたとしても、 動作としては正しいんだよね。 154 名前：デフォルトの名無しさん [2009/10/03(土) 21:37:43 ] spinlockはアンフェアだからそれで正しいね。 155 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 22:29:57 ] ＞spinlockはアンフェアだからそれで正しいね。 それは答えになってるのか？？ 156 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 23:21:32 ] 間違いではない＝正しい という論理がわからないのか？ どうしょうーもねーな 157 名前：デフォルトの名無しさん mailto:sage [2009/10/03(土) 23:32:43 ] 正しいのか？って言ってんじゃなくて 答えになってるのか？ って言ってんだけど。 158 名前：デフォルトの名無しさん mailto:sage [2009/10/04(日) 00:51:01 ] 答えにはなっているように見える。「正しいのか？」という問いに「正しい」と答えている。 その答えが正しいのかどうかは別の話。 159 名前：デフォルトの名無しさん mailto:sage [2009/10/04(日) 03:29:21 ] ja.wikipedia.org/wiki/%E3%83%99%E3%83%B3%E5%9B%B3 160 名前：デフォルトの名無しさん mailto:sage [2009/10/05(月) 13:09:01 ] >>155 説明になっているかどうかはともかく 答えにはなっていると思うんだが。 161 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 02:20:13 ] 火元の人 　やり方が理解できない質問者 　俺に分からないならこのスレにも理解できる奴いないんじゃね、とか思っていて、 　それが態度にも滲み出ている 煽る人 　分かってるつもりだけど分かってないで煽り続ける 　こいつを見た火元は「やっぱり分かってる奴いないんじゃないか」と思いこむ 住人タイプA 　一目で分かるがお前の態度が気に入らないしコード示すのマンドクセ 　つーかこの説明で分かれボユゲ 住人タイプB 　みんな何言ってんだかわかんね ちょっと違うけどこのパターンに似てる 162 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:48:32 ] posix準拠のオーソドックスなやり方しかしない俺にはこのスレは不要なようだ おまえら何言ってるかわかんねぇーしｗ 163 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 10:36:30 ] >>162 自分からPOSIXスレッドとかに関連したネタをふればいいんじゃないかな？ まあ正直なところ、ここは相談室スレなんだから、あまりにもハードウェア寄りな専門知識が 必要な話題については、できれば「並列化について語る」スレで熱く語ってくれって感じはしてる。 あっちはハード(マルチプロセッサ/マルチコア)全然オケーなスレなんだから。 164 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 13:09:43 ] 単に自分の付いていけないレベルの話題を締め出したいだけに見える 165 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 13:35:03 ] ということにしたいだけにも見える 166 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 21:17:55 ] つーか俺はposix準拠な世界で生きてきたので。 おまえらよくposix非準拠な話題で盛り上がれるなーｗ 167 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 22:48:54 ] >>166 CASやメモリバリアなどはpthreadライブラリの実装者にとっても 必須の知識だよ。 168 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 23:10:22 ] >>167 利用者にとっては？ 169 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 03:21:14 ] POSIX厨としか言いようがない 170 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 08:47:16 ] >>169 POSIX使うのが普通じゃないの？ 171 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 13:13:35 ] pthreadにはアトミック操作が定義されてないから、 単なるカウンタのインクリメントでも いちいちロックしなきゃならんのが嫌だ。 172 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 00:37:47 ] なんでPOSIXで厨なんだよ(´・ω・｀) 173 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 02:28:34 ] POSIXスレッド以外の話題ってだけで叩くなら完全に厨だろ 174 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 06:51:32 ] 他人を厨と決めつける人が厨に見える 175 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 08:03:36 ] 何でも鸚鵡返しすれば反論になると思ってるだろ 176 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 08:04:58 ] baka 177 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 08:09:28 ] pthread地獄 part 2 pc12.2ch.net/test/read.cgi/unix/1166620307/ ここへ行けばいいのに 178 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 03:19:26 ] 　　　 　 　 　 ／＼　　　　　　　　　　　 　 ┌┐　　　　　　　 　 　 ┌┐　　　　 　 ___ ___ 　　　 　 　 ／　__　＼　　　　　 　／＼　 ..｜｜.. 　／＼　 　　 　 ｜｜　　　　___ ＼＼ ＼ 　　　 　 ／　／ .＼　＼　　　　　＼ 　＼ .｜｜. ／　 ／　┌──┘└──、＼＼ ￣ ￣ 　　　 ／　／ 　 　 .＼　＼　　　　　＼／ .｜｜. ＼／　　 └──┐┌─ 、｜　|__| 　　／　／ ┌──┐.＼　＼　 ┌───┘└───┐　 　 　 .｜｜　 ｜｜ 　..＼／ 　 └┐┌┘　 .＼／　└───┐┌───┘　　　　 /　/　　｜｜ 　　 　 　 　┌┘└┐　　　 　 　 　 ／＼ .｜｜. ／＼　　　　　　/　/ 　　/　/ 　　 　 　 　└┐┌┘　　　 　 　 ／　 ／ .｜｜. ＼　 ＼　　　／　/　　 /　/ 　　 　 　┌─┘└─┐　　　　　＼／　 ..｜｜..　 ＼／　　 ＼／　 　 /　/ 　　 　 　└────┘　　　　　　　　　　└┘　　　　　　　　　　　 　 ＼/ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 ....､ ....................--------､,　　 　 　 　 　 i~ﾞ7　　 r‐ｯ　　　　!ﾞﾞ.!　　　　　　 !　! : !―――;;;;;;''''''''ゝ ,,ﾉ゛　　　 ._　　　/ ./　　 .,! .,!　　　　!　!　　.,..............!　ヽ..........-、 　　　　　 |　|.／ ／ 　　　　 .l､,｀''-./ ./ 　　　!　!　　　　|　|　　 ――ｰｯ .iｰ''''''''i　| 　　　　　 |　l'-‐゛　　　　　　　 ｀ﾞｯ　 .ゝ､　　 .|　|　　　　|　,!　　　　　 ./ ./　　　!　! 　　　　 ../ .,!　　 　 　 　 　 　 ／.,ｒ'"＼,/　　.!ｰ′　　 ./ .,!　　　　 . / ./　　　 | │ 　　　 .,./ ./ 　　　　　　 　,..‐" ／ 　　 　　　　　　　 . /　/ 　　　 .／../ 　　　 ./ .lﾞ 　　.ｒ'".／　　 　 　 　 　 ゝ／゛　　　　　　　　　 : ,,-'゛.／　　　 .〈　/ 　　 .'|,ﾞ,ﾞ,,,, " 　　 .｀゛　　　　　　　　　　　　　　　　　　　　　　　 ﾞ'''" 179 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 15:39:31 ] その “全米” はグアム島を含むのでしょうか。 180 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 19:08:01 ] グアム、どうなんだろ。州に昇格すればいいのに。まあ、しないだろうけど。 181 名前：デフォルトの名無しさん [2009/11/03(火) 00:02:53 ] スレッドを終了させるときは_endthreadexじゃなく そのままreturnでもいいのか？スタックの開放されない？ 182 名前： ◆0uxK91AxII mailto:sage [2009/11/03(火) 00:28:01 ] 良い。 mallocで取ってきた領域をfreeしなくて良いのと同じくらいに。 スタックとやらは、_endthreadexとは無関係。 183 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 00:59:57 ] freeしろよ 184 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 01:16:04 ] スレッドに強くないのに書き込んでみる。 ttp://msdn.microsoft.com/ja-jp/library/hw264s73(VS.80).aspx >ただし _endthread または _endthreadex は、_beginthread や _beginthreadex の >パラメータとして渡されたルーチンからスレッドが戻ると自動的に呼び出されます。 ってことで、returnすれば問題ないかと。 どちらかというと >_endthread と _endthreadex によって、C++ デストラクタはスレッドで保留状態になり、呼び出されません なので、呼ばないほうが好ましいような。 185 名前： ◆0uxK91AxII mailto:sage [2009/11/03(火) 01:52:01 ] 182は無かった事にしてください。 んゆ。 186 名前：184 mailto:sage [2009/11/03(火) 14:42:55 ] スレッドに強い人に補強して欲しいのだけど、それとも184の認識で問題なし？ 187 名前： ◆0uxK91AxII mailto:sage [2009/11/03(火) 17:34:11 ] Microsoft Visual Studio\VC98\CRT\SRC\THREADEX.C んゆ。 188 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 17:55:09 ] 問題なし 189 名前：デフォルトの名無しさん [2009/11/03(火) 22:08:15 ] スレッド識別子って何なんだ？ 何に使うの？ 190 名前：デフォルトの名無しさん mailto:sage [2009/11/03(火) 22:25:48 ] 殺したり、止めたり。 191 名前：デフォルトの名無しさん mailto:sage [2009/11/04(水) 21:43:06 ] 他スレッドの変数の中身知ることってできないかな？ 192 名前：デフォルトの名無しさん mailto:sage [2009/11/04(水) 21:55:11 ] メモリ空間は共有しているので、アドレスがわかれば普通に参照できる。 193 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 12:32:06 ] win32のインターロックをクリティカルセクションと 同じように使ったら早くて驚いた。 両者の内部的な違い・利点・欠点てなんですかね？ 194 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 14:06:45 ] そもそも用途が違うんじゃない？ インターロックは変数1個ぶんの更新しかできないでしょ？ インターロックを使ってクリティカルセクションと同様のものを作ることはできるだろうし、 クリティカルセクションを使ってインターロックと同様のものを作ることもできるだろうけど、 そういう話？ 195 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 14:31:15 ] インターロック一発で出来ることならインターロックで。 196 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 14:54:32 ] win32のクリティカルセクションは衝突しなければインターロックと同じくらい早いんだなこれが 197 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 16:01:33 ] いや倍くらいは遅いだろう。 198 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 16:15:02 ] んだ。インターロックで済むならそれが数倍早い。 199 名前：193 mailto:sage [2009/11/05(木) 19:29:23 ] 今以下のクラスでクリティカルセクションと同じように扱ってテストしてるんだ。 class InterLock { private: LONG m_Flag; public: void Enter() { while(InterlockedCompareExchange(&m_Flag,1,0)) Sleep(0); } void Leave() { InterlockedCompareExchange(&m_Flag,0,1); } public: InterLock() { m_Flag = 0; } virtual ~InterLock() { } }; 200 名前：193 mailto:sage [2009/11/05(木) 19:30:08 ] こっちはクリティカルセクション晩 class CriticalSection { private: CRITICAL_SECTION cs; public: void Enter() { EnterCriticalSection(&cs); } void Leave() { LeaveCriticalSection(&cs); } public: CriticalSection() { InitializeCriticalSection(&cs); } virtual ~CriticalSection() { DeleteCriticalSection(&cs); } }; 201 名前：193 mailto:sage [2009/11/05(木) 19:43:57 ] //グローバル変数 ロッククラス g_Lock; int g_i = 0; // 三つのスレッドで以下を走らせる void Run() { for(int i=0; i<10000000; i++) { g_Lock.Enter(); g_i++; g_Lock.Leave(); } } int main() { //３つのスレッドでRun()を走らせ、スレッド終了まで待機 (...省略) cout << g_i << endl; cout << time.result() << endl; return 0; } 結果 クリティカルセクション 35秒　g_i = 30000000 インターロック 5.5秒　g_i = 30000000 ロッククラス無し 0.16秒 g_i = 21203536(整合性無し) 環境　OS:win xp CPU:core2duo1.8G メモリ:3G 202 名前：デフォルトの名無しさん mailto:sage [2009/11/05(木) 20:42:07 ] ソースまともに見てないけど、CSがもしインライン化されないなら性能的には勝てない だろうしなぁ まぁ、asm読めば全て分かるだろうけど 203 名前： ◆0uxK91AxII mailto:sage [2009/11/05(木) 23:23:50 ] TryEnterCriticalSection ~ Sleepだとどうなるの、っと。 threadをCPUと1:1にbindしたらどうなるの、っと。 timesliceを変えたらどうなるの、っと。 結果は書かない方が良い。 204 名前：193 mailto:sage [2009/11/06(金) 07:01:38 ] ＞TryEnterCriticalSection ~ Sleepだとどうなるの、っと。 これだけやってみた。 上記のテストだとインターロックとの差は0.5秒内、 つまりほとんど差がなくなった 205 名前：デフォルトの名無しさん mailto:sage [2009/11/06(金) 13:00:12 ] プロセッサ数が2以上ならSpinWaitにしたらどうなる？ あとインターロックのIncrementでダイレクトアップデートにしたらどうなる？ 206 名前： ◆0uxK91AxII mailto:sage [2009/11/06(金) 20:26:47 ] 違うネタだけど。 #include <windows.h> #include <tchar.h> #include <stdio.h> #include <stdlib.h> #define THREADS 64 #define LOOPS 123456789 struct SData { LARGE_INTEGER m_cntBegin; LARGE_INTEGER m_cntEnd;}; DWORD WINAPI thread(LPVOID pArg); int __cdecl cmpForSort(const void *pArg0, const void *pArg1); int _tmain() { int i; HANDLE ahThread[THREADS]; SData aData[THREADS]; LARGE_INTEGER diff; for (i=0; i<THREADS; i++) ahThread[i] = CreateThread(NULL, 0, thread, &aData[i], 0, NULL); WaitForMultipleObjects(THREADS, ahThread, TRUE, INFINITE); qsort(aData, THREADS, sizeof SData, cmpForSort); for (i=0; i<THREADS; i++) { CloseHandle(ahThread[i]); diff.QuadPart = 0<i? aData[i].m_cntBegin.QuadPart - aData[i-1].m_cntBegin.QuadPart: 0; _tprintf(_T("thread: %d, diffBegin: %I64d, clock: %I64d\n"), i, diff.QuadPart, aData[i].m_cntEnd.QuadPart-aData[i].m_cntBegin.QuadPart); } return 0; } 207 名前： ◆0uxK91AxII mailto:sage [2009/11/06(金) 20:28:49 ] DWORD WINAPI thread(LPVOID pArg) { SData *pData; DWORD value; float sum; pData = (SData *)pArg; QueryPerformanceCounter(&pData->m_cntBegin); __asm { mov ecx, LOOPS fldz LOOP_: fadd QWORD PTR value dec ecx jnz LOOP_ fstp DWORD PTR sum } QueryPerformanceCounter(&pData->m_cntEnd); return 0; } int __cdecl cmpForSort(const void *pArg0, const void *pArg1) { LARGE_INTEGER diff; diff.QuadPart = ((SData *)pArg0)->m_cntBegin.QuadPart - ((SData *)pArg1)->m_cntBegin.QuadPart; if (0 > diff.QuadPart) return -1; if (0 < diff.QuadPart) return 1; return 0; } 208 名前： ◆0uxK91AxII mailto:sage [2009/11/06(金) 20:37:44 ] 同じ処理なのに所要時間がブレるとか、 先に開始したthreadよりも、後から開始した方が早く処理を終えるとか。 そういうのが起こりうる。 computer gameでmulti threadの利用に消極的な理由の一つだと思う。 209 名前：193 mailto:sage [2009/11/06(金) 23:12:33 ] >>205 ＞インターロックのIncrementでダイレクトアップデートにしたらどうなる？ 1.3秒だった >SpinWait これC#じゃん 210 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 01:40:37 ] スピン待機はC#限定じゃなく一般的な概念だ 211 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 09:40:03 ] スピンすると余計遅くなりそうだな。 一般的な使用状況に比べて処理と競合がタイトすぎるせいかな多分。 212 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 09:45:49 ] ああつまり3スレッド同時じゃなくて1スレッドで3回繰り返した方が速いとかっていう状態ね。 213 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 17:33:40 ] あーいやいや、これだとちょっと書き方がおかしいな…まあいいや 214 名前：193 mailto:sage [2009/11/07(土) 19:49:07 ] スピンロックは信頼性がないという話を聞いたような。 さて上記のベンチですが、1スレッドで3回繰り返したほうがずっと早いです。 衝突したときに別の処理をせずに待つ場合はシングルスレッドにした方がいいかも。 215 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 20:02:47 ] スピンロックに信頼性が無かったらどうすんだよｗ 全然仕組みとか分かってなくて使ってる匂いがぷんぷんするな 216 名前：デフォルトの名無しさん mailto:sage [2009/11/07(土) 20:03:53 ] スピンロックとスピンウェイトは基本的に別物です。 217 名前：デフォルトの名無しさん mailto:sage [2009/11/08(日) 00:12:02 ] それと信頼性に何の関係が？ 218 名前：デフォルトの名無しさん mailto:sage [2009/11/08(日) 02:55:49 ] スピン待ちの話をされてスピンロックどうこうと返すのがおかしい 219 名前：デフォルトの名無しさん mailto:sage [2009/11/08(日) 10:06:21 ] 上の人じゃないけど、スピンロックはスピンウエイトを使ってやってるかとおもてたよ(´・ω・｀) 220 名前： ◆0uxK91AxII mailto:sage [2009/11/08(日) 12:45:22 ] spinlockでlockできる保証は無いね。 偶然上手く動いているだけ。 221 名前：デフォルトの名無しさん mailto:sage [2009/11/09(月) 01:48:53 ] ◆0uxK91AxIIで検索したら、NGしてもいいくらいトンチンカンな奴だな 222 名前：デフォルトの名無しさん mailto:sage [2009/11/10(火) 14:27:27 ] トリップ付けるような奴だもの。 223 名前：デフォルトの名無しさん mailto:sage [2009/11/10(火) 20:06:21 ] トンチンカンなんて久々に見た おやつあげないわよ 224 名前：デフォルトの名無しさん mailto:sage [2009/11/11(水) 09:14:41 ] 抜作先生の方がまだ新しいな。 225 名前：デフォルトの名無しさん mailto:sage [2009/12/15(火) 00:01:41 ] マルチスレッド対応の基数木のアルゴリズムって どうやって記述すればいいのでしょうか？ CかC++で探しています。 226 名前：デフォルトの名無しさん mailto:sage [2009/12/22(火) 22:31:16 ] 読み込みと書き込みが１スレッドずつの場合でもメモリ破壊って起きるのでしょうか？ たとえば、ある変数をメインスレッドで読み込み続け、 複数のサブスレッドで、クリティカルセクションを用い、書き込むといった場合です 227 名前：デフォルトの名無しさん mailto:sage [2009/12/22(火) 22:39:31 ] >>226 とりあえず破壊読み出しメモリだと死ぬよね。 228 名前：デフォルトの名無しさん mailto:sage [2009/12/22(火) 23:29:29 ] >>226 まずメモリ破壊を定義してもらおうか 229 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 01:41:11 ] パソコンのネジ外して開けると見えてくるメモリの部分をハンマーで叩く 230 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 01:42:27 ] ハードウェア的な話題もするんか 231 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 02:21:03 ] 宇宙線による確率的なビット反転は防ぎようがない 232 名前：226 mailto:sage [2009/12/23(水) 10:10:00 ] データが飛ぶという意味でのメモリ破壊です ハード的にどのように動作しているのか分からないのですが 同アドレスに同時にアクセスされることによってメモリ破壊が起きるのでしょうか？ 233 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 10:20:05 ] 書き込みをクリティカルセクションで同期して、クリティカルセクションを抜けたところで可視性が保証されたとしても、 読む方が書き込み中にその変数を見る可能性があるなら、少なくとも意図しない値を読む可能性はあるんじゃない？ (+不変な変数見てると思われるかもね) 要求次第だけど、 この手のポーリングするやつは、次に読めればいいからその瞬間のスナップショットで十分だと思うので、 Atomicな操作用のAPI使うとか、書き込みがAtomicであることが保証されるならvolatileだけでもいいかも。 その変数の読み書きだけ同期とっても、読んでる間の書き込みは防げても、 読み込みが終わってクリティカルセクション抜けたあと、それで処理しようと思ったら もう書き換わってることもあるし。 読んだ値の処理が終わるまで書き込ませないなら、話は別だけど。 234 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 11:15:37 ] 昔使ったタイマ LSI でラッチ→lo-read→hi-readって いう約束ごとのあるやつがあったな。hi-readでラッチ が外れる奴。word-read 命令が使えるかどうかは CPU 次第。 235 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 12:47:17 ] >>226 ハードや操作による。 つーか、まずは「アトミックな操作」という概念をどっかで調べとけ。 例えば、x86のCPUなんかだと、どういう操作がアトミックかはIntelが規定している。 アトミックな書き込みなら、別のコアからの読み込みが割り込む可能性は無い。逆に アトミックでない書き込みなら、例えば半分くらい書き込んだところで別のコアが 読み込む可能性があるということ。 x86なら、厳密な規定はIntelの英語版サイトに落ちてる。32bitアラインドなreadや writeは確実にアトミックだ。相当古いx86以外はキャッシュアラインドなら大丈夫。 read-modify-writeはLOCKプリフィクスが無い限りアトミックではないが、xchg 命令はLOCK#が自動的にアサートされるのでアトミックだ。 まぁ、アセンブラを直接叩くんじゃなければ、イントリンシック命令を調べておけば 十分だが、その裏でどういうCPUの動きをしているかは理解しといた方がいい。 つーか、低水準の話と高水準の話で全然違いすぎるんだよな。俺はどっちの話でも 構わんけど、分けた方がいいのか？ 236 名前：226 mailto:sage [2009/12/23(水) 12:53:08 ] ありがとうございます もっと勉強します 237 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 13:31:19 ] >>232 そんな事は起きないようにハードウェアが作られてる 物理的なメモリへのアクセス経路は1個しかないから、同じアドレスに同時にアクセス なんて事は出来ない 命令が書いた順に実行されるかとか、他のコアやスレッド云々は >>235 の通り 238 名前：デフォルトの名無しさん mailto:sage [2009/12/23(水) 13:31:47 ] クリティカルセクションを用いって書いてあるから、なんとなくWindowsかと思ってた。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef