マルチスレッドプログラミングについて語るスレ
■前スレ
マルチスレッドプログラミング相談室 その8
http://toro.2ch.net/test/read.cgi/tech/1253521167/
■過去スレ
その1 ttp://pc3.2ch.net/tech/kako/997/997345868.html
その2 ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その3 ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その4 ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その5 ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/
その6 ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
その7 ttp://pc12.2ch.net/test/read.cgi/tech/1215253576/
OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【OS】
【言語】
【実行環境】
【その他特記する事項】
探検
マルチスレッドプログラミング相談室 その9
2012/06/15(金) 01:31:57.88
2012/09/01(土) 15:58:04.54
スレッドの割り当てとかはOSが決めてることだからね
OSの挙動に影響しないようなことを考えながらやりませう
マルチCPUじゃなく
単一CPUの時のスレッド等の挙動を考えてみませう
OSの挙動に影響しないようなことを考えながらやりませう
マルチCPUじゃなく
単一CPUの時のスレッド等の挙動を考えてみませう
2012/09/01(土) 16:04:51.98
同じプロセッサ内のコアを移動するならまだしも、別のプロセッサに移動してしまったら、
せっかく溜め込んだキャッシュがおじゃんになってしまうのではないでしょうか?
せっかく溜め込んだキャッシュがおじゃんになってしまうのではないでしょうか?
2012/09/01(土) 16:11:29.80
逝ってるなマルチコアはCPU毎に命令データキャッシュ持ってるでしょ
2012/09/01(土) 16:12:43.77
でも分岐したらダメなのでは?
2012/09/01(土) 16:16:42.15
よく考えたら、分岐するんだったらCPU移らなくてもダメだった
ドピュッ
ドピュッ
2012/09/01(土) 16:27:35.25
命令の先読みとかやってるの知ってる?
同じ領域を読み込む場合に早くなるってのがキャッシなのでは?
HDDキャッシュとかも同じでしょ
同じ領域を読み込む場合に早くなるってのがキャッシなのでは?
HDDキャッシュとかも同じでしょ
2012/09/01(土) 16:29:03.73
別のプロセッサに移動してしまったらキャッシュとかおじゃんになってしまうかもしれないが、
ひとつのプロセッサに多数のスレッドが集中して別のプロセッサを遊ばせておくくらいならいくつかのスレッドを移した方がいい場合もある
OSの裁量次第
ひとつのプロセッサに多数のスレッドが集中して別のプロセッサを遊ばせておくくらいならいくつかのスレッドを移した方がいい場合もある
OSの裁量次第
2012/09/01(土) 16:32:16.93
キャッシュ知らんでも
スレッド系のプログラム作るのには関係無いような
速度ウンタラは動いてから考えればいい話でしょ
スレッド系のプログラム作るのには関係無いような
速度ウンタラは動いてから考えればいい話でしょ
2012/09/05(水) 01:11:52.99
初心者の質問です
new;した領域 p があって
スレッドAは条件によってdelete p;をする
スレッドBはpを参照する
この時に
変数 blReference, blDeletingを使って
Aの処理中 delete部分
while( blReference ){ Sleep(1); }
blDeleting= true;
delete p;
p = NULL;
blDeleting = false;
Bの処理中 参照部分
while( blDeleting ){ Sleep(1); }
blReference = true;
char* cp = (char*)p:
//以下参照
blReference = false;
っていうのは安全でしょうか?
new;した領域 p があって
スレッドAは条件によってdelete p;をする
スレッドBはpを参照する
この時に
変数 blReference, blDeletingを使って
Aの処理中 delete部分
while( blReference ){ Sleep(1); }
blDeleting= true;
delete p;
p = NULL;
blDeleting = false;
Bの処理中 参照部分
while( blDeleting ){ Sleep(1); }
blReference = true;
char* cp = (char*)p:
//以下参照
blReference = false;
っていうのは安全でしょうか?
2012/09/05(水) 04:17:50.83
>>57
先ず基本的にblReference, blDeletingとも、きちんと扱えるようにしないとダメ。
要は、OSの用意しているクリティカルセクションなどの機構を使う必要がある。
つーか、マルチスレッドプログラミングの基本なんだが、大丈夫なんか?
それと、cpにNULLが代入されること自体は問題ないの?
先ず基本的にblReference, blDeletingとも、きちんと扱えるようにしないとダメ。
要は、OSの用意しているクリティカルセクションなどの機構を使う必要がある。
つーか、マルチスレッドプログラミングの基本なんだが、大丈夫なんか?
それと、cpにNULLが代入されること自体は問題ないの?
2012/09/05(水) 06:16:48.24
weak_ptr使えハゲと言うしかないレベル
2012/09/05(水) 08:13:29.83
weak_ptrってboost?
マルチスレッドを考慮されていたの?
マルチスレッドを考慮されていたの?
2012/09/09(日) 01:13:55.50
2012/09/09(日) 01:44:44.97
volatile使ったとしてもコンパイラによっては安全だとは言えないんだよ
2012/09/09(日) 01:51:51.18
安全って、思いたい理由の方に興味があるんだけど
2012/09/09(日) 07:41:49.96
むしろ安全だといえるコンパイラを知りたい
2012/09/09(日) 14:24:32.10
volatile使っても結果変わらない事の方が多い気がする
2012/09/09(日) 15:54:34.19
そりゃそうだ
2012/09/09(日) 16:30:00.96
安全だと思うと、コンピュータがそれを理解して動いてくれると思いたいのかな
2012/09/12(水) 00:03:54.96
volatileしてダメだったケースに遭遇したことないなあ。
まあboolでの同期・排他は簡単なケースにしか使ってなくて、
まじめなのはcritical sectionとかmutexで排他・同期するから
気がついてないだけかもしれないけど。
まあboolでの同期・排他は簡単なケースにしか使ってなくて、
まじめなのはcritical sectionとかmutexで排他・同期するから
気がついてないだけかもしれないけど。
2012/09/12(水) 07:22:51.47
>>57
>// スレッドA
>while( blReference ){ Sleep(1); } // 1
>blDeleting= true; // 3
>// スレッドB
>while( blDeleting ){ Sleep(1); } // 2
>blReference = true; // 4
スレッドの処理が時間的に番号の順で行われる場合がある。
つまり、この処理はスレッド間の排他にはなっていない。
おとなしくクリティカルセクションを使ってロックした方がいい。
>// スレッドA
>while( blReference ){ Sleep(1); } // 1
>blDeleting= true; // 3
>// スレッドB
>while( blDeleting ){ Sleep(1); } // 2
>blReference = true; // 4
スレッドの処理が時間的に番号の順で行われる場合がある。
つまり、この処理はスレッド間の排他にはなっていない。
おとなしくクリティカルセクションを使ってロックした方がいい。
2012/09/22(土) 01:53:58.20
>>69
InterlockedExchangePointerは?
InterlockedExchangePointerは?
2012/09/29(土) 20:38:32.52
質問ですが、Windows APIのSetEvent()やWaitForSingleObject()って、
内部で適切にメモリバリアを行うことが保証されていますか?
例えば、下記のケースにおいて、_WriteBarrier()や_ReadBarrier()は冗長?
(メインスレッド側)
bTerminate = true; // volatile bool型
_WriteBarrier();
SetEvent(hEvent); // スレッドを起床させる
(ワーカースレッド側)
WaitForSingleObject(hEvent); // 起床されるまで待つ
_ReadBarrier();
if (bTerminate) { .... } // メインスレッドから通知されたbTerminateに基づく処理
内部で適切にメモリバリアを行うことが保証されていますか?
例えば、下記のケースにおいて、_WriteBarrier()や_ReadBarrier()は冗長?
(メインスレッド側)
bTerminate = true; // volatile bool型
_WriteBarrier();
SetEvent(hEvent); // スレッドを起床させる
(ワーカースレッド側)
WaitForSingleObject(hEvent); // 起床されるまで待つ
_ReadBarrier();
if (bTerminate) { .... } // メインスレッドから通知されたbTerminateに基づく処理
2012/09/29(土) 20:49:37.13
も一個、volatile bool a, b; があるとして、
a = c;
b = d;
の代入順序は、a, bがたとえatomicな型でvolatileだからといって
プロセッサのアウトオブオーダー実行のレベルでは実施される順序が保たれる保証はない、
よって、上記代入を行ったコア以外のコアからaやbを代入順序依存で参照する場合は
メモリバリアが 必 須 、
という理解で合っていますか
a = c;
b = d;
の代入順序は、a, bがたとえatomicな型でvolatileだからといって
プロセッサのアウトオブオーダー実行のレベルでは実施される順序が保たれる保証はない、
よって、上記代入を行ったコア以外のコアからaやbを代入順序依存で参照する場合は
メモリバリアが 必 須 、
という理解で合っていますか
2012/09/29(土) 21:08:56.80
>>71
http://msdn.microsoft.com/en-us/library/ms686355%28VS.85%29.aspx
> The following synchronization functions use the appropriate barriers to ensure memory ordering:
> ・Functions that enter or leave critical sections
> ・Functions that signal synchronization objects
> ・Wait functions
> ・Interlocked functions
>>72
はい
http://msdn.microsoft.com/en-us/library/ms686355%28VS.85%29.aspx
> The following synchronization functions use the appropriate barriers to ensure memory ordering:
> ・Functions that enter or leave critical sections
> ・Functions that signal synchronization objects
> ・Wait functions
> ・Interlocked functions
>>72
はい
2012/09/30(日) 00:03:39.72
>>64
javacやcscじゃね
javacやcscじゃね
2012/09/30(日) 00:12:53.41
メモリバリアってのはgcc特有の表現で
atomicな処理とは関係ないんだけど
atomicな処理とは関係ないんだけど
2012/09/30(日) 00:30:58.05
2012/09/30(日) 00:56:39.75
ただの最適化抑止のおまじないみたいなもんだよ
2012/09/30(日) 01:05:56.81
>>77
ちょっそれvolatileの方wwwww
まあ>73の通り、Windows API内部でよろしくやってくれるので普通はメモリバリアの方は意識しなくて良いっぽい
おそらくUNIXのシステムコールも同様でよろしくやってくれるから知る人ぞ知る知識になってしまうのだろう…
ちょっそれvolatileの方wwwww
まあ>73の通り、Windows API内部でよろしくやってくれるので普通はメモリバリアの方は意識しなくて良いっぽい
おそらくUNIXのシステムコールも同様でよろしくやってくれるから知る人ぞ知る知識になってしまうのだろう…
79デフォルトの名無しさん
2012/09/30(日) 01:13:58.152012/09/30(日) 01:14:33.03
gccのvolatileってのは、ちょっと特殊なんだよ
2012/09/30(日) 01:21:19.22
>>77,78
真相はもっと複雑怪奇だったりする
http://yamasa.hatenablog.jp/entries/2009/07/20
http://msdn.microsoft.com/ja-jp/library/bb310595%28VS.85%29.aspx
つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…
真相はもっと複雑怪奇だったりする
http://yamasa.hatenablog.jp/entries/2009/07/20
http://msdn.microsoft.com/ja-jp/library/bb310595%28VS.85%29.aspx
つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…
2012/09/30(日) 01:26:29.84
ここらへんの話は
・(インラインでない)関数呼び出しの副作用を恐れてコンパイラが最適化を自粛
・volatileによって明示的に最適化が抑制
・システムコール内でメモリバリアの面倒をみてくれる
・ハードウェアがコア間でキャッシュのコヒーレンスをとってくれる
といった事情が絡み合った結果、運よく問題を生じないケースも多々あるので
コードをバリバリ書いているような人でもきちんと理解していないことがある(あった)
・(インラインでない)関数呼び出しの副作用を恐れてコンパイラが最適化を自粛
・volatileによって明示的に最適化が抑制
・システムコール内でメモリバリアの面倒をみてくれる
・ハードウェアがコア間でキャッシュのコヒーレンスをとってくれる
といった事情が絡み合った結果、運よく問題を生じないケースも多々あるので
コードをバリバリ書いているような人でもきちんと理解していないことがある(あった)
2012/09/30(日) 01:27:48.80
アトミック変数とか作って、ド素人に誤解釈されたらどうすんだろ、この人
2012/09/30(日) 02:22:23.12
>>81
> つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…
そこで面倒を見てくれるのは「release/aquireメモリバリアとしてのみ」であることに注意。
http://yamasa.hatenablog.jp/entry/20090816/1250446250
こっちのSequential consistencyの性質は、VC++2005以降のvolatileでも持っていない。
> つまり、VC++2005以降である限り、volatileを使うとメモリバリアも面倒をみてくれるらしい…
そこで面倒を見てくれるのは「release/aquireメモリバリアとしてのみ」であることに注意。
http://yamasa.hatenablog.jp/entry/20090816/1250446250
こっちのSequential consistencyの性質は、VC++2005以降のvolatileでも持っていない。
2012/09/30(日) 13:33:02.65
>>83
ドシロウトがなんでスレッド使った開発に加わるんだよ
ドシロウトがなんでスレッド使った開発に加わるんだよ
2012/09/30(日) 13:35:58.01
なんで排他の話ばっか出てくるんだ。
スレッド間で書き換えしまくるような変数なんて殆ど無いだろ。
それはともかく、C++向けのクロスプラとフォームなスレッドキューって無いものか。
スレッド間で書き換えしまくるような変数なんて殆ど無いだろ。
それはともかく、C++向けのクロスプラとフォームなスレッドキューって無いものか。
2012/09/30(日) 14:26:20.27
2012/09/30(日) 15:13:14.28
>>86
スレッドの実装が違うだろう、LinuxとUNIXなら同じだが
スレッドの実装が違うだろう、LinuxとUNIXなら同じだが
2012/09/30(日) 15:25:27.37
>>85
じゃあ、うわっつらの言葉だけ知ってる甘ちゃん系ではどう?
じゃあ、うわっつらの言葉だけ知ってる甘ちゃん系ではどう?
2012/09/30(日) 16:54:17.48
2012/09/30(日) 17:01:09.98
2012/09/30(日) 21:04:28.14
おまえら何回C++におけるatomicとvolatileの話を繰り返せば気がすむの
2012/09/30(日) 21:20:03.98
それしかネタがないからさ
2012/09/30(日) 22:09:45.89
>>92
スレッドキューの話しだせ
スレッドキューの話しだせ
2012/09/30(日) 23:24:16.01
だって手法なんて先駆者が出し尽くしただろ
2012/09/30(日) 23:53:26.29
スレッドキューって何だ?
スレッドセーフなキューってことか?
それともGCDみたいなタスクキューのことか?
スレッドセーフなキューってことか?
それともGCDみたいなタスクキューのことか?
2012/10/01(月) 00:06:38.53
タスクキューのことだよ。
てかスレッドセーフなキューってなんだよ。それだったら
別にキューに限定せずスレッドセーフなコンテナの話でいいだろ。
てかスレッドセーフなキューってなんだよ。それだったら
別にキューに限定せずスレッドセーフなコンテナの話でいいだろ。
2012/10/01(月) 07:53:47.16
java.util.concurrent.BlockingQueueのことだろ
2012/10/12(金) 23:18:24.02
同期処理を間違いなく設計するための、何か良い手法やツールはないですかね?
ペーペーのビギナーだというのもあるのですが、
複数のmutexを混在させなければいけない時にぼんやり書いたコードでデッドロックを発生させたり、
waitに到達していないのにシグナル発射する可能性のあるコードを書いてしまって、
そのデバッグで無駄に体力を消耗しています
ペーペーのビギナーだというのもあるのですが、
複数のmutexを混在させなければいけない時にぼんやり書いたコードでデッドロックを発生させたり、
waitに到達していないのにシグナル発射する可能性のあるコードを書いてしまって、
そのデバッグで無駄に体力を消耗しています
100デフォルトの名無しさん
2012/10/13(土) 11:18:48.75 馬鹿には無理
101デフォルトの名無しさん
2012/10/13(土) 13:05:32.66102デフォルトの名無しさん
2012/10/13(土) 18:57:49.84103デフォルトの名無しさん
2012/10/13(土) 22:12:39.46 >>101
やんないと、他に仕事ないんで・・・・
>>102
かなり頭がよくないと、サラリと正しいコード書けないですよね(棋士的な意味の頭のよさ)
そうか、地道にやるしかないのか(´・ω・`)
・・・売り物なんですねimagix
自分の担当業務以外にも使えそうなので、ちょっとチーム内に紹介してみます
とりあえず、今の自分のレベルでミスりやすいところを正しく実装するための比喩をいくつか考案中です
↓
例1
スレッド間同期は、キャッチボール
ボールを受け取る側は、しゃがんでいないとボールをキャッチできない
例2
スレッド再開時の手順は、競馬のスタートと同じ
@ゲートを閉じる(送信側mutexロック)
A馬がゲート前に並ぶ(受信側wait)
Bファンファーレが鳴る(signal)
Cゲートが開く(送信側mutex開放)
やんないと、他に仕事ないんで・・・・
>>102
かなり頭がよくないと、サラリと正しいコード書けないですよね(棋士的な意味の頭のよさ)
そうか、地道にやるしかないのか(´・ω・`)
・・・売り物なんですねimagix
自分の担当業務以外にも使えそうなので、ちょっとチーム内に紹介してみます
とりあえず、今の自分のレベルでミスりやすいところを正しく実装するための比喩をいくつか考案中です
↓
例1
スレッド間同期は、キャッチボール
ボールを受け取る側は、しゃがんでいないとボールをキャッチできない
例2
スレッド再開時の手順は、競馬のスタートと同じ
@ゲートを閉じる(送信側mutexロック)
A馬がゲート前に並ぶ(受信側wait)
Bファンファーレが鳴る(signal)
Cゲートが開く(送信側mutex開放)
104デフォルトの名無しさん
2012/10/13(土) 23:51:02.32 mutexなんか使わずfuture、promisで凌げ
105デフォルトの名無しさん
2012/10/14(日) 17:05:55.79106デフォルトの名無しさん
2012/10/14(日) 18:33:06.95 まず10年間C++を勉強しろ
107デフォルトの名無しさん
2012/10/14(日) 20:43:53.62 >>106
C++関係ないやん
C++関係ないやん
108デフォルトの名無しさん
2012/10/15(月) 01:03:58.39109デフォルトの名無しさん
2012/10/15(月) 09:17:51.40 結局無理てことか、初心者というより基本が
110デフォルトの名無しさん
2012/10/21(日) 14:23:48.88111デフォルトの名無しさん
2012/10/21(日) 14:42:59.60112デフォルトの名無しさん
2012/10/21(日) 23:06:50.68 Joel on softwareの和訳ページ『間違ったコードは間違って見えるようにする』
を紹介しようと思ったが今ちょっと繋がらないようなので原文で読んでちょ↓↓↓
http://www.joelonsoftware.com/articles/Wrong.html
を紹介しようと思ったが今ちょっと繋がらないようなので原文で読んでちょ↓↓↓
http://www.joelonsoftware.com/articles/Wrong.html
113デフォルトの名無しさん
2012/10/26(金) 20:45:55.33 教えてください
g++でコンパイルしたプログラムのプロファイリング、特にスレッドの動作の
効率を見たいのですが、Linux環境で使える定番のフリーツールはないでしょうか?
g++でコンパイルしたプログラムのプロファイリング、特にスレッドの動作の
効率を見たいのですが、Linux環境で使える定番のフリーツールはないでしょうか?
114デフォルトの名無しさん
2012/10/28(日) 11:59:56.78 gdb
115デフォルトの名無しさん
2012/10/28(日) 21:28:29.42 マ
ジ ハ ,,ハ
デ (;゚◇゚)z
!?
ジ ハ ,,ハ
デ (;゚◇゚)z
!?
116デフォルトの名無しさん
2012/12/05(水) 09:54:15.94 プロファイラでわかるのはどの部分が処理時間の何%を使ってるか
ぐらいであって、スレッドの動作効率なんていう個人の価値観みたい
なものは測定できんだろ。
ぐらいであって、スレッドの動作効率なんていう個人の価値観みたい
なものは測定できんだろ。
117デフォルトの名無しさん
2012/12/31(月) 15:20:38.31 C#です。
C#ではローカル変数にvolatileを付けられませんが
以下の場合、最適化でスレッドの変更が反映されない場合はありますか?
var init = new ManualResetEventSlim(false);
int val = 0;
var t = new Thread(() =>
{
val = …; // valに何らかの値を入れる
init.Set(); // valを初期化したことを知らせる
:
// スレッドの処理が続く
};
t.Start();
init.Wait(); // スレッドでvalが初期化されるまで待つ
// valを使う。スレッドでの変更が反映されている?
C#ではローカル変数にvolatileを付けられませんが
以下の場合、最適化でスレッドの変更が反映されない場合はありますか?
var init = new ManualResetEventSlim(false);
int val = 0;
var t = new Thread(() =>
{
val = …; // valに何らかの値を入れる
init.Set(); // valを初期化したことを知らせる
:
// スレッドの処理が続く
};
t.Start();
init.Wait(); // スレッドでvalが初期化されるまで待つ
// valを使う。スレッドでの変更が反映されている?
118デフォルトの名無しさん
2012/12/31(月) 16:48:21.02 あります
119デフォルトの名無しさん
2012/12/31(月) 19:09:35.15 >>118
どういった理由でしょうか?
http://www.albahari.com/threading/part4.aspx
>The following implicitly generate full fences:
>Setting and waiting on a signaling construct
という記述を見つけたのですが、これによれば
valへの書き込みをinit.Set()より後に、valからの読み込みをinit.Wait()より前に
という事は行われないように思えるのですが。
どういった理由でしょうか?
http://www.albahari.com/threading/part4.aspx
>The following implicitly generate full fences:
>Setting and waiting on a signaling construct
という記述を見つけたのですが、これによれば
valへの書き込みをinit.Set()より後に、valからの読み込みをinit.Wait()より前に
という事は行われないように思えるのですが。
120デフォルトの名無しさん
2013/01/01(火) 04:47:40.84 判ってるのに質問するなボケが
121デフォルトの名無しさん
2013/01/01(火) 12:37:44.23 それを否定されたから理由を聞いてるんじゃないのか
122デフォルトの名無しさん
2013/01/04(金) 04:09:28.62 C#が自ら自身の仕様を質問すること自体が。
まぁ、人間だって自身についてどれだけ知っているか怪しいもんだが。
まぁ、人間だって自身についてどれだけ知っているか怪しいもんだが。
123デフォルトの名無しさん
2013/01/05(土) 12:19:18.18 >>96
の発言で思い出した。
GCDといえば、最近WindowsとLinuxにも移植されたっぽいんだよね。
http://opensource.mlba-team.de/xdispatch/docs/current/index.html
pThreadとかWin32スレッドをローレベルで使うよりお手軽な気がする。
ちょっと試してみるわ。
の発言で思い出した。
GCDといえば、最近WindowsとLinuxにも移植されたっぽいんだよね。
http://opensource.mlba-team.de/xdispatch/docs/current/index.html
pThreadとかWin32スレッドをローレベルで使うよりお手軽な気がする。
ちょっと試してみるわ。
124デフォルトの名無しさん
2013/01/05(土) 18:17:06.97 123だけど、
XDispatchだが、Windowsであっけなく使えた。
こりゃいいぜ。Win、Mac、Linuxで同一ソースでGrand Central Dispatchが使える。
マルチスレッドプログラミング新時代到来って感じだw
XDispatchだが、Windowsであっけなく使えた。
こりゃいいぜ。Win、Mac、Linuxで同一ソースでGrand Central Dispatchが使える。
マルチスレッドプログラミング新時代到来って感じだw
125デフォルトの名無しさん
2013/01/08(火) 19:15:30.57 XDispatchの導入記事を書いてみた。
https://docs.google.com/document/pub?id=1miIRZh8QteYzjIiU7GjcGSshTp470qHbRQUh0wf12Sw
突っ込みどころあったらご指摘よろ。
https://docs.google.com/document/pub?id=1miIRZh8QteYzjIiU7GjcGSshTp470qHbRQUh0wf12Sw
突っ込みどころあったらご指摘よろ。
126デフォルトの名無しさん
2013/01/08(火) 20:13:02.13 libdispatch + α、って感じなのか
127デフォルトの名無しさん
2013/01/09(水) 01:22:43.52 >>126
そうみたい。
基本的にはマルチプラットフォームでやりたい場合は${ ~ }の記法とautoを使えばオッケー。
他にも標準のlibdispathには無い機能とか、Qtユーザー向けのQtDispatchとかあるみたいだけど、そこまではまだ調べられてない。
時間があったらもっと調べてみて、追記してみるよ。
そうみたい。
基本的にはマルチプラットフォームでやりたい場合は${ ~ }の記法とautoを使えばオッケー。
他にも標準のlibdispathには無い機能とか、Qtユーザー向けのQtDispatchとかあるみたいだけど、そこまではまだ調べられてない。
時間があったらもっと調べてみて、追記してみるよ。
128デフォルトの名無しさん
2013/01/30(水) 19:59:09.23 Win32でのプロセス間リソース共有の仕方で悩んでます
1. ポーリング=Mutexで保護された共有リソースの変更を常に監視
2. サーバー(orクライアント)スレッドでEvent監視+Mutexで共有リソースを保護
余計なCPUリソースを食うのはどちらなんでしょうか?定性的な評価と理由を教えてください
(定性的な評価=プロファイルで調べろは無しでお願いします)
自分は「重さ:Mutex>>>>Event>>>>>>>CriticalSection」というイメージがあるので、
2のマルチスレッドのコンテキストスイッチの重さを考慮しても1の方が重いのではないかと考えています
1. ポーリング=Mutexで保護された共有リソースの変更を常に監視
2. サーバー(orクライアント)スレッドでEvent監視+Mutexで共有リソースを保護
余計なCPUリソースを食うのはどちらなんでしょうか?定性的な評価と理由を教えてください
(定性的な評価=プロファイルで調べろは無しでお願いします)
自分は「重さ:Mutex>>>>Event>>>>>>>CriticalSection」というイメージがあるので、
2のマルチスレッドのコンテキストスイッチの重さを考慮しても1の方が重いのではないかと考えています
129デフォルトの名無しさん
2013/01/30(水) 20:42:56.62 (゚Д゚)ハァ?
Mutexを奪い合えばいいだけだし。
Mutexを奪い合えばいいだけだし。
130デフォルトの名無しさん
2013/01/30(水) 21:22:17.63 Event vs. Pollingは宗教戦争
131デフォルトの名無しさん
2013/01/30(水) 21:52:45.99 何もすることがなきゃ寝て待ってればいいだけ
何かしたけりゃイベント来るまでしてればよかろう
何かしたけりゃイベント来るまでしてればよかろう
132デフォルトの名無しさん
2013/01/31(木) 08:42:39.84 Mutexが重いんじゃなくてポーリングが重いんだろ
イベントやメッセージ等の非同期通知が使えるなら、そっちのほうが軽いのは当然
イベントやメッセージ等の非同期通知が使えるなら、そっちのほうが軽いのは当然
133デフォルトの名無しさん
2013/01/31(木) 22:24:51.03 >>128
> Win32でのプロセス間リソース共有の仕方で悩んでます
winすれで聞いたら
> 余計なCPUリソースを食うのはどちらなんでしょうか?定性的な評価と理由を教えてください
人から聞いたことを信じるの?
> Win32でのプロセス間リソース共有の仕方で悩んでます
winすれで聞いたら
> 余計なCPUリソースを食うのはどちらなんでしょうか?定性的な評価と理由を教えてください
人から聞いたことを信じるの?
134デフォルトの名無しさん
2013/02/01(金) 07:29:56.93 効率を気にする香具師が2chで質問するとかもうね
135デフォルトの名無しさん
2013/02/17(日) 17:37:32.78 >>79ではx86、x64では(P6〜)
RAR WAR WAW RAW
× × × × ... × 順序の逆転が起きる WAR ... Write after Read (書いてから読む)
となってるけど>>81のMSDNでは WAR のみ逆転が起こる、書いてる。
RAR WAR WAW RAW
○ × ○ ○
どっちが正しいのでしょうか?
あと、MSDNの英語の原文はこっちだけど
http://msdn.microsoft.com/en-us/library/windows/desktop/ee418650(v=vs.85).aspx
Reads moving ahead of writes の訳が
「読み取りを書き込みの先に移動する」
「書き込みの前に読み取りを移動」
と2回出てきて紛らわしい。
write
...
read
この順番が逆になることあり、てことだよね?
RAR WAR WAW RAW
× × × × ... × 順序の逆転が起きる WAR ... Write after Read (書いてから読む)
となってるけど>>81のMSDNでは WAR のみ逆転が起こる、書いてる。
RAR WAR WAW RAW
○ × ○ ○
どっちが正しいのでしょうか?
あと、MSDNの英語の原文はこっちだけど
http://msdn.microsoft.com/en-us/library/windows/desktop/ee418650(v=vs.85).aspx
Reads moving ahead of writes の訳が
「読み取りを書き込みの先に移動する」
「書き込みの前に読み取りを移動」
と2回出てきて紛らわしい。
write
...
read
この順番が逆になることあり、てことだよね?
136デフォルトの名無しさん
2013/02/17(日) 21:17:44.97 >>135 それ RAW じゃね
シングルスレッドのメモリ命令は RAW (対象アドレスが被らない) と
WAW (命令による) の特定ケースを除いて命令順通り、
マルチスレッドの各スレッド間では、全パターンに入れ替えの可能性あり。
たぶん MSDN の記載は誤解を招くかと。
こちらの根拠は以下の Volume 3A, Chapter 8.2
Intel 64 and IA-32 Architectures Software Developer's Manuals
ttp://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
write -> 0x1000
...
read -> 0x2000
と明らかに異なる場所へのアクセスであり、... の間に他のメモリアクセスが
無ければ、read を write の前に持ってきても結果は変わらないはず。
シングルスレッドのメモリ命令は RAW (対象アドレスが被らない) と
WAW (命令による) の特定ケースを除いて命令順通り、
マルチスレッドの各スレッド間では、全パターンに入れ替えの可能性あり。
たぶん MSDN の記載は誤解を招くかと。
こちらの根拠は以下の Volume 3A, Chapter 8.2
Intel 64 and IA-32 Architectures Software Developer's Manuals
ttp://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
write -> 0x1000
...
read -> 0x2000
と明らかに異なる場所へのアクセスであり、... の間に他のメモリアクセスが
無ければ、read を write の前に持ってきても結果は変わらないはず。
137デフォルトの名無しさん
2013/02/18(月) 21:54:23.31 >>135
WARはレジスタリネーミングと同じだよ。
上書きするなら依存関係が切れるので命令の実行順序は入れ替え可能になる。
結果を内部で保持しておいて後で書き出す。
そして実際のメモリの内容は命令の順序通りの結果になる(ならなかったら大変)。
でいいかと。
WARはレジスタリネーミングと同じだよ。
上書きするなら依存関係が切れるので命令の実行順序は入れ替え可能になる。
結果を内部で保持しておいて後で書き出す。
そして実際のメモリの内容は命令の順序通りの結果になる(ならなかったら大変)。
でいいかと。
138137
2013/02/18(月) 22:30:08.38 >>137の補足しとくと、同一プロセッサでも異なるアドレスだとリオーダ可能なので
順序が重要な場合はメモリフェンスが必要になる。
別のプロセッサ間でもリオーダ可能ということになる。
別のプロセッサとの同じメモリに対するアクセス順序はタイミング次第で複雑なので
必要に応じてロックプレフィックスを使う。
順序が重要な場合はメモリフェンスが必要になる。
別のプロセッサ間でもリオーダ可能ということになる。
別のプロセッサとの同じメモリに対するアクセス順序はタイミング次第で複雑なので
必要に応じてロックプレフィックスを使う。
139デフォルトの名無しさん
2013/02/18(月) 23:53:52.86140デフォルトの名無しさん
2013/02/19(火) 07:57:34.41 >>139
キャッシュラインがコピーされた状態ではRARの順番は替わりうると思うけど
RAW自体は入れ替わらないんじゃないかな。
実際のWriteの前にReadが割り込む可能性があるけど、それはタイミング次第ってことで。
キャッシュラインがコピーされた状態ではRARの順番は替わりうると思うけど
RAW自体は入れ替わらないんじゃないかな。
実際のWriteの前にReadが割り込む可能性があるけど、それはタイミング次第ってことで。
141デフォルトの名無しさん
2013/02/19(火) 09:15:14.16 lockプリフィックス使うんじゃあ
142デフォルトの名無しさん
2013/02/23(土) 20:04:20.23 >>139
そうか、マルチスレッドでもリオーダは無いな。他から割り込まれる可能性があるだけだ。
そうか、マルチスレッドでもリオーダは無いな。他から割り込まれる可能性があるだけだ。
143135
2013/02/23(土) 23:41:17.41 >>136-142さん、さんくすでした。
MDSNが正しかったのですか。
> それ RAW じゃね
でした。コードの順番と英語表記は逆になるんですよね。誤解してました・・・。
この辺を勉強する本とかないでしょうか?
「The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで」
は読んでみたのですがロックレスアルゴリズムの原理だけでCPUごとの実装は
なかったのであまり役にたたなかったです。
MDSNが正しかったのですか。
> それ RAW じゃね
でした。コードの順番と英語表記は逆になるんですよね。誤解してました・・・。
この辺を勉強する本とかないでしょうか?
「The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで」
は読んでみたのですがロックレスアルゴリズムの原理だけでCPUごとの実装は
なかったのであまり役にたたなかったです。
144デフォルトの名無しさん
2013/02/24(日) 10:17:55.94 ハードウェアを実装するとなったらそれこそ本一冊どころではすまないだろうけど、
データの同期に関しては何が危険でどうすれば安全に扱えるかが区別できればいいんじゃない?
だから本を買って読むほどでもないような。
CPU内の順序はOut of Orderが関係していて、CPUは可能な限り速く実行しようとするから
順番が入れ替わってしまうってことで、それをコントロールするのにメモリバリア命令がある。
アセンブラの最適化にも関係してるから、プロセッサの最適化マニュアルとかも参考になるかも。
マルチプロセッサではキャッシュコヒーレンシやMESIプロトコルとかの概略を知ってればいいんじゃないかな。
他のプロセッサに割り込まれて困る部分にはlockで保護するとか。
データの同期に関しては何が危険でどうすれば安全に扱えるかが区別できればいいんじゃない?
だから本を買って読むほどでもないような。
CPU内の順序はOut of Orderが関係していて、CPUは可能な限り速く実行しようとするから
順番が入れ替わってしまうってことで、それをコントロールするのにメモリバリア命令がある。
アセンブラの最適化にも関係してるから、プロセッサの最適化マニュアルとかも参考になるかも。
マルチプロセッサではキャッシュコヒーレンシやMESIプロトコルとかの概略を知ってればいいんじゃないかな。
他のプロセッサに割り込まれて困る部分にはlockで保護するとか。
145デフォルトの名無しさん
2013/02/26(火) 14:50:30.35 Java の資料だけど「コンパイラ開発者のためのJSR133クックブック」ってのはどう?
146デフォルトの名無しさん
2013/02/27(水) 12:54:04.48147デフォルトの名無しさん
2013/02/27(水) 23:21:29.29 RafterWってシングルスレッドなら絶対安全?
途中で実行cpuが変わってもosが面倒見てくれるから気にする必要はないってこと?
実行cpuが変わることあるかしらないけど
まぁ普通にコード書いてて入れ替わる訳ないから大丈夫か
途中で実行cpuが変わってもosが面倒見てくれるから気にする必要はないってこと?
実行cpuが変わることあるかしらないけど
まぁ普通にコード書いてて入れ替わる訳ないから大丈夫か
148デフォルトの名無しさん
2013/03/02(土) 16:47:32.29149デフォルトの名無しさん
2013/03/03(日) 20:26:49.52 >>148
書き方が悪かった。
マルチプロセッサの環境でシングルスレッドのコードを実行してて、
実行CPUが変わったとしても読み書き順が入れ替わらないでしょう?
そこはOSがプロセス切り替え時に勝手にバリアをかけてるはずだよね?ってこと
書き方が悪かった。
マルチプロセッサの環境でシングルスレッドのコードを実行してて、
実行CPUが変わったとしても読み書き順が入れ替わらないでしょう?
そこはOSがプロセス切り替え時に勝手にバリアをかけてるはずだよね?ってこと
レスを投稿する
ニュース
- 日本行き空路49万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約32%に相当 ★4 [ぐれ★]
- 【音楽】Perfume・あ~ちゃんの結婚相手「一般男性」は吉田カバンの社長・吉田幸裕氏(41) 高身長で山本耕史似 [Ailuropoda melanoleuca★]
- 【大分】佐賀関で大規模火災、170棟以上が延焼中 70代男性1人と連絡取れず [ぐれ★]
- 【サッカー】日本代表MF 中村敬斗 ボリビア戦のスーパーゴールに「惚れるわ」「痺れる程のゴールこれでご飯何杯いけるのよ」 [阿弥陀ヶ峰★]
- 【サッカー】U-17日本代表、激闘PK戦制す 北朝鮮撃破で6大会ぶり8強入り U17W杯 [久太郎★]
- 「クマはなるべく山に返す努力を」「クマと戦争は間違っている」動物保護活動家の主張 棲み分けと学習放獣でクマ被害なくなるのか?★7 [ぐれ★]
- アンケート調査で「高市発言は問題なし」 93.5%wwwwwwwwwwwwwwwwwwwwwwwww [279254606]
- 【悲報】大分市佐賀関の火事、20軒→170軒に延焼🔥 [481941988]
- 自閉症が「んなっしょい」と連呼するお🏡
- 日本人の海外旅行したきのマナーよくなったのはいつから
- へそグリグリ
- 結婚しないやつは異性は嫌いなの?
