- 1 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]
- マルチスレッドプログラミングについて語るスレ
■前スレ
マルチスレッドプログラミング相談室 その６
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
■過去スレ
その１ 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/
OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他突起する事項】
- 335 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 14:23:51 ]
- よくあることです。
- 336 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 14:40:12 ]
- 何を試したんだよ
- 337 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 17:25:44 ]
- キアイ
- 338 名前：デフォルトの名無しさん [2008/12/13(土) 19:48:33 ]
- あるスレッドで処理した結果をメインスレッドに渡したいのだがどうすればいい？
_beginthreadexの第3引数に結果用のポインタを渡せばいいのか
- 339 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 20:43:24 ]
- 典型的にはソウデスナ
処理してほしい内容と
処理結果の格納場所を
与えるのがよろしいかと思いますダ
- 340 名前：デフォルトの名無しさん mailto:sage [2008/12/14(日) 01:39:30 ]
- >>338
CPUにお祈りする
- 341 名前：デフォルトの名無しさん mailto:sage [2008/12/14(日) 02:58:11 ]
- >>334
マルチスレッド化して速くなるかどうかは状況による。
その状況がわからなきゃ、何とも言えない。
- 342 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 07:49:17 ]
- >>338
グローバル変数でいいよ
メモリ空間を共有してるのがスレッドのメリットなんだし
- 343 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 09:18:38 ]
- …
- 344 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 11:09:40 ]
- volatile最強
- 345 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 11:13:32 ]
- >>388
俺はそういう場合スレッドセーフなスマートポインタ使うな
スレッドにデータを渡す前に参照カウント増やしといて
スレッド側では使い終わったら解放
メインスレッドは結果が必要なくなればスレッドが終了していなくてもデータを解放できる
- 346 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 11:22:01 ]
- クラスにしてthis渡してるな
class tiny_thread abstract {
protected:
HANDLE m_hthread;
unsigned m_id;
： いろいろメンバー
private:
static unsigned WINAPI thread_start(void *o) {
tiny_thread *tt = (tiny_thread *) o;
return tt->run();
}
public:
bool start() {
m_hthread = (HANDLE) _beginthreadex(NULL, 0, thread_start, this, 0, &m_id);
return m_hthread != 0;
}
virtual int run() = 0;
};
- 347 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 15:41:15 ]
- >>388は素人童貞
- 348 名前：デフォルトの名無しさん mailto:sage [2008/12/16(火) 15:56:58 ]
- >>388 に期待
- 349 名前：デフォルトの名無しさん mailto:sage [2008/12/17(水) 01:34:39 ]
- ・メインスレッドが必ずサブスレッドより長生きするようにする。
メインがサブをjoinなり必要に応じて中断するなりする。
・結果格納場所のポインタやコールバック関数のアドレスをサブに渡す。
メインがUIスレッドの場合、サブからPostThreadMessageした方が楽かも知れない
・通信用メモリの解放責任をメイン側と決めておく
>>345みたいなサブスレッドだけ生き続ける設計は個人的に(GCの無い言語では)嫌だ
これらが難しいと思うなら>>342だね。カッコ悪いけど確実かな
- 350 名前：デフォルトの名無しさん mailto:sage [2008/12/17(水) 01:53:27 ]
- PostThreadMessageは取りこぼしが発生するので使っちゃいけません。
PostMessageを代わりに使おう。
- 351 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 00:19:42 ]
- ところで、ファイバーってどうなん。
アイドル状態のスレッドでパカパカやって動かすとか
スケジュール処理なワーカスレッド代わりとかしか思い浮かばん。
漏れは、スレッドの処理は概ね、待ち処理とか先行処理なので、
あまり使い方が思い浮かばない。
- 352 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 01:51:56 ]
- >>351
ファイバーは移植のためにあるようなもので
新規プロジェクトで使う価値は無に等しい。
- 353 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 02:10:30 ]
- >>352
短絡杉
プリエンプティブであることは必ずしも望ましいことじゃない。
ゲームではファイバーが好まれる。
Larrabeeでもシェーダはファイバーで実装されるそうだ。
マルチコアでハイパフォーマンスだすためにファイーバーは重要。
- 354 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 02:31:59 ]
- 自分でコンテキストスイッチとかめんどくせぇぇぇ
- 355 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 03:01:53 ]
- ちまちま排他処理すんのめんどくせぇぇぇ
- 356 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 12:21:50 ]
- >>352、353
マルチスレッドで複数の関数叩くのと、ファイバーを複数キックするのの違いってやっぱ、
同期処理が不必要(他のスレッドでキック中のファイバーは自動的に同期される？)だとか
スタックの制限(ファイバーキックされた段階でスタック指定できる)ですか？
いえ、無論色んな意味合いで違うことは判るけど。
- 357 名前：デフォルトの名無しさん [2008/12/20(土) 16:20:24 ]
- int result = write( buf, size );
if( result == -1 && errno == EAGAIN ) SwitchNextCoroutine();
I/Oイベントドリブンなスケジューラをみたことある。↑みたいなの。
あとは同期が要らないってのが素晴らしい。
- 358 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 20:34:51 ]
- VisualStudio 2010にはC#のyieldを使ったファイバーもどきライブラリが付いてくるらしいね
channel9.msdn.com/posts/Charles/George-Chrysanthakopoulos-CCR-and-DSS-Visual-Toolkit-2008/
- 359 名前：デフォルトの名無しさん mailto:sage [2008/12/20(土) 23:50:27 ]
- それは歪でいまいちだね〜
まずコルーチンがあって
それにスケジューラを足してファイバー
イテレータ風に味付けしてジェネレータ(C#のyieldのことね)
という階層があるべき姿だと思うな。
- 360 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 00:18:47 ]
- 64CPU環境でスレッドを256本生成したときに
struct data[2000];
なんてあって、dataの個々の要素を排他的にアクセスしたい場合
pthread_mutex以外に使えそうな手段ってありますか？
CASってどうやって使うのかよくわからんし助けて
- 361 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 00:48:43 ]
- pthread_mutexでマズい理由は？
- 362 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 00:58:20 ]
- >>361
2000個もpthread_mutex_tって用意して使えるのですかね？
- 363 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 01:08:25 ]
- 発想が変？
- 364 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 01:47:06 ]
- mutexを2000個作って問題ないと思うよ。
自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
でパフォーマンスの問題が出たらそのときに対処を考える。
reader-writerロックが使えれば使う。
- 365 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 01:47:49 ]
- 訂正。
> 自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
struct data[2000] ね。
- 366 名前：デフォルトの名無しさん mailto:sage [2009/01/10(土) 18:28:23 ]
- >>362
pthread_mutex_t はただのデータだから、何個作っても
そのプロセスのメモリ以外の資源は使わない
- 367 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 00:54:05 ]
- 連結リストをCAS使って実装するときのお手本ってありますか？
- 368 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 01:04:19 ]
- >>367
ttp://www.cs.rochester.edu/u/michael/PODC96.html
- 369 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 01:14:01 ]
- 双方向は無いのか........................
- 370 名前：デフォルトの名無しさん mailto:sage [2009/01/11(日) 01:50:26 ]
- 双方向でできると思ってんのかっ
- 371 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 00:40:02 ]
- rw_lockAPIが存在する環境で
同じrw_lock変数を以下のような構造で使うのって
問題ないでしょうか。
func()
{
rw_lock(read)
if 条件{
rw_lock(write)
rw_unlock(write)
}
rw_unlock(read)
}
- 372 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 02:34:03 ]
- オレオレOSのオレオレrw_lock APIなら大丈夫だけど？
- 373 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 13:24:35 ]
- 実装次第だが、普通に考えるとデッドロックするな
- 374 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 21:32:54 ]
- r_lock 確保してるんだから if の中の w_lock が取れないだろjk
- 375 名前：デフォルトの名無しさん mailto:sage [2009/01/20(火) 06:28:27 ]
- なぜrでロックしないといけないのかわからんけど、条件に関わるのか？
- 376 名前：デフォルトの名無しさん mailto:sage [2009/01/20(火) 11:21:30 ]
- >>375
このパターン自体は典型的なケースだろ
APIによっては、ReaderとWriterの他に「Writerに変更可能なReader」が用意されていることもある
- 377 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 16:00:09 ]
- WindowsでCreateThread中Cランタイムに含まれる関数を使うとリークを起こすとありますが、
普段からCreateThreadは使わずbeginthreadを使ったほうがいいんですか？
完全にCランタイム使わずってのも面倒だし、内部で使ってる関数があるかもしれない
そういうことまで考えてあえてCreateThreadを使うメリットはあるのでしょうか？
- 378 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 16:06:34 ]
- 軽い
- 379 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 16:14:38 ]
- ない
- 380 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 17:56:15 ]
- _beginthreadexでおｋ
- 381 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 14:15:26 ]
- ないな
- 382 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 13:59:30 ]
- pthreadでmutexで
再起ロックする場合と
依存関係をハッキリさせてスレッドIDとFAST_MUTEXで判別
どっちが高速ですか？
- 383 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 15:33:29 ]
- 後者。
以前計測したことがある。
ただし、依存関係の洗い出し作業がとても大変だった。
デッドロックに直結するから、とても気をつけないといけない。
要求性能がシビアだったから後者で仕事のためにやったけど、趣味ならば前者をお薦めする。
排他制御がボトルネックになるようなら、前者で実装すればいい。
俺の場合は、本当に特殊で制限が厳しかったから前者でやっただけ。
- 384 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 15:35:13 ]
- ×排他制御がボトルネックになるようなら、前者で実装すればいい。
○排他制御がボトルネックになってから、後者で実装すればいい。
- 385 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 15:38:02 ]
- FAST_MUTEXって何？
- 386 名前：383 mailto:sage [2009/02/01(日) 16:18:24 ]
- 色々ぐだぐだだな。
お家で寝たいよ。
- 387 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 23:25:11 ]
- struct hoge{
int var
pthread_mutex_t m;
struct hoge * next;
};
こんな構造体あって
while(h){
pthread_mutex_lock(h->m);
h->var++;
pthread_mutex_unlock(h->m);
h = h->next;
}
こんな風にリンクリストを舐める前後を排他して
舐めていくという処理は正しいでしょうか？
- 388 名前：デフォルトの名無しさん mailto:sage [2009/02/01(日) 23:54:31 ]
- 加算をアトミックにしたいなら正しいんじゃない。
- 389 名前：デフォルトの名無しさん mailto:sage [2009/02/02(月) 00:06:27 ]
- >>388
では、これもレースコンディション無く
検索可能ですかね？
struct hoge{
int var;
int id;
pthread_mutex_t m;
struct hoge * next;
};
void search(id)
{
while(h){
pthread_mutex_lock(h->m);
if( h->id == id){
h->var++;
pthread_mutex_unlock(h->m);
return;
}
pthread_mutex_unlock(h->m);
h = h->next;
}
}
- 390 名前：デフォルトの名無しさん [2009/02/09(月) 14:04:10 ]
- shared_ptrで管理するオブジェクトAをスレッドXに渡し、スレッドXからdllを呼んで、dll内でオブジェクトAのメモリを確保する、
ということをしたいのですが、以下のコードでjoin終了時、shared_ptr<A>の解放処理のところで例外が発生します。
どういった理由が考えられるでしょうか？
マルチスレッドでもdllを使わなければ問題なし、dllを使ってもマルチスレッドにしなければ問題なしでした。
struct A {}; // スレッドXにshared_ptrで渡されるデータ
typedef void (__cdecl* DllFunc)(std::tr1::shared_ptr<A>& a); // スレッドから呼ばれるDLL
struct X { // boost::threadに渡すスレッドオブジェクト
std::tr1::shared_ptr<A> a_;
X(std::tr1::shared_ptr<A> a) : a_(a) {} // DLLに渡すデータ
void operator()(void) { // スレッド実行時に呼ばれる関数
HMODULE handle = LoadLibrary(L"dll_func.dll");
DllFunc dll_func = (DllFunc)GetProcAddress(handle, "dll_func");
dll_func(a_);
FreeLibrary(handle);
c.notify_one();
}
};
int main(int argc, char** argv) {
std::tr1::shared_ptr<A> a(new A);
std::tr1::shared_ptr<X> x(new X(a));
boost::thread th(*x);
th.join(); // ここで例外発生
}
<dll_func.cpp>
BOOL WINAPI DllMain (HINSTANCE hinstDll, DWORD fdwReason, LPVOID lpvReserved) { return TRUE; }
extern "C" __declspec(dllexport) void __cdecl dll_func(shared_ptr<A>& a) { a.reset(new A); // これがなければ大丈夫 }
- 391 名前：デフォルトの名無しさん mailto:sage [2009/02/09(月) 15:33:18 ]
- よりによってここに書くか。すれ違いだWin32スレ行け。
DLLの勉強一からやりなおせ。
最初から全コードのせときゃもっと早く回答ついたんだろうが、ウザイからオシエネ。
- 392 名前：デフォルトの名無しさん mailto:sage [2009/02/09(月) 16:58:44 ]
- DLL内でnewしたのをEXE内で解放したらエラー出るんじゃない？
そもそもshared_ptrだって内部で参照カウント用にnewしてるからDLLじゃ使えない気がするなー。
- 393 名前：392 mailto:sage [2009/02/09(月) 17:02:58 ]
- スレッドは全然関係ないね。うん。
- 394 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 05:13:43 ]
- >>390
たぶんこれだけで死ねる。
std::tr1::shared_ptr<A> a(new A);
X(a)();
- 395 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 21:54:55 ]
- DLLか・・・COMについて調べたほうがいいんじゃないですかね
いろいろヒントあるよ
- 396 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 15:33:17 ]
- shared_ptr使ってるくせにdeleter知らないとか
- 397 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:31:28 ]
- >>288
Windows Xp home SP3 で自作のTCPサーバ運用してるけど、インバウンド接続の
同時接続数の制限が10ってことはないよ。
今モニタ見ても20人くらい繋がってる。
p2pがすごい数でつながってるだろうし
この件についてはいろいろなひとがよく確かめずにいろいろ書いてる。
自分でちょっとやってみればすぐわかる。
- 398 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:33:34 ]
- >>397
実装はともかくライセンスで制限されてるはず
- 399 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:37:37 ]
- そうなんだよね。 使わないでくれという約束で みんな破って使ってるわけだ。
- 400 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:46:20 ]
- SQLだったかで試してたときにイベントログに制限されたメッセージが
出たことある。あとShare動かしてる時とか頻繁に出る気がする。
単純にセッションの制限では無かった筈。
- 401 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:12:50 ]
- MS製のサーバは独自に制限した実装 IISじゃなくてPWSだっけ
WMEとかはレジストリいじって50人くらいつないだりしてたな。
- 402 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 02:13:42 ]
- それとは別に、セキュリティ的な話で、
SYN_SENTなソケットをシステム全体で
10くらいしか持てないって制限もあったはず。
- 403 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 19:23:55 ]
- 初心者な質問ですが、
Thread A Thread B
for(;;) for(;;)
printf("AAA\n"); printf("BBB\n");
という処理を行うと、AAA行とBBB行が入り乱れて表示されるんですが、
AABABB\n\n などと表示されることはありえないんでしょうか。
環境はWindows XPで、VC++2008EEでプログラムを書いてます。
- 404 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 19:36:03 ]
- >>403
ここらへんに何か書いてあるんじゃねーの？
msdn.microsoft.com/ja-jp/library/172d2hhw.aspx
- 405 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 04:04:56 ]
- >>403
バッファリング
- 406 名前：デフォルトの名無しさん [2009/02/23(月) 21:19:24 ]
- スレッドに別のスレッドから信号を送って途中で処理をキャンセルしたいのですが、
現状、以下のようにしています。
void run() { // スレッド実行部
for () { // 長いループ
...処理...
if (check()) return; // 処理をキャンセル
}
}
check()でキャンセルのフラグをチェックし、このフラグを別のスレッドから書き換えるという方法です。
でもこの方法だとループ内の処理が重くなったときにキャンセル操作に対する反応も遅くなってしまうため
どうしたものかと悩んでます。
スレッド内でタイマーのようなものを発行して、定期的にcancel()のチェックをするといった方法はできないでしょうか？
環境はVC9です。
- 407 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 22:47:56 ]
- >>406
別スレッドから強制停止するとリソースリークの元だよ。
if (check()) return; // 処理をキャンセル
を重い処理の途中に幾つか入れる方がまし。
- 408 名前：406 mailto:sage [2009/02/23(月) 23:51:22 ]
- >>407
> を重い処理の途中に幾つか入れる方がまし。
どうも。やっぱりこういう単純な方法しかないですか。
重い処理を別スレッドで行わせながら
キャンセル操作の反応がよい安全な方法ってのはないんでしょうか。
cancel()を挿入しまくるというのもなんだかスマートじゃないなぁ･･･。
- 409 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 00:50:35 ]
- 非同期に飛ばされるぐらいならコードが汚くなる方が良い
と思うのは俺だけじゃないよな？
- 410 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 01:12:42 ]
- その重い処理ってのがなんなのか
スマートとか言うならその重い処理をスマートに分割すりゃいいじゃない
どうしてもチェックしまくりたくないっていうなら処理を持ってるクラスのインスタンスを急にnullにしてやって
例外捕らえて終了してしまえ、最悪だけど
- 411 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 01:40:59 ]
- 別プロセスにして殺すってのは？
結局そういうのって要求されるキャンセル応答時間次第。
人間相手ならmsecオーダでおｋでしょ。
きっとループ1回につき1msecもかからないのでは？
- 412 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 01:51:03 ]
- ワーカースレッド2つ以上用意にして
対処すればよくね？
複数個のスレッドでビジー状態になるなら
その処理内容そのものを分割しタスク化した方がいい
- 413 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 02:50:07 ]
- 違う質問スレで質問した後でこちらを見つけたので一応こちらでも・・・
CreateThread関数で第三引数をクラスのメンバ関数にしたい場合は
どういう記述をすればいいのか教えてください
よろしくお願いします
- 414 名前：468 mailto:sage [2009/02/24(火) 02:56:15 ]
- >>410
>その重い処理ってのがなんなのか
例えば大きなサイズの行列計算や、待ち行列を使った探索問題なんかを想定しています。
問題を分割することはある程度はできるんですが、それはそれで頑張るとして、
それ以外のアプローチははないかなと。
>>411
> 別プロセスにして殺すってのは？
すみません。よくわかりません。
別プロセスならば殺しても元のプロセスに影響がでないという意味でしょうか。
>>410の後半で言ってることに近い
>>412
> ワーカースレッド2つ以上用意にして 対処すればよくね？
同じスレッドオブジェクトをAとBの２つ用意して、
Aが動いてるときにキャンセルしたときはキャンセルしたふりをして
（Aの計算は次のcancel()チェックまで続いてる）、
新規の呼び出しがあったときはBを動かすというイメージですか？これはいけるかも…。
- 415 名前：468 mailto:sage [2009/02/24(火) 02:58:01 ]
- 一部修正
>>410の後半で言ってることに近い
↓
>>410の後半で言ってることに近いですか？
- 416 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 07:10:44 ]
- >>413
コールバック関数にはstaticなメンバ関数(クラスメソッド)しか使えない。
コールバック関数を使うAPIは大抵ポインタ型の引数を渡せるから、
クラスを使いたいときはそこにthisポインタを渡して使う。
- 417 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 08:52:04 ]
- >>413
できない
普通の関数作ってその中で呼び出す
- 418 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 16:53:09 ]
- >>416‐417
ありがとうございます
とりあえず、>>417の方法でやってみます
- 419 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 20:52:23 ]
- >>414
別プロセスにすると、ターミネートしたときのリソースの開放をＯＳがやってくれる
ってことではあるまいか。
それはともかく、その長い処理がうまく分割できず、どうしても時間がかかる場合は
汎的には、キャンセルボタンの入力を取得する側（フラグを立てる側ね）で、キャンセルが
押されたからしばらく待てっていうサインをユーザーに与える方が重要な希ガス。
- 420 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 21:45:33 ]
- 別プロセスのほうがクリーンアップの点では簡単＆安心だなあ
ただ、多くの情報を受け渡したり、途中で通信が必要だったりすると
しんどいけどな
- 421 名前：デフォルトの名無しさん mailto:sage [2009/02/24(火) 23:05:03 ]
- しんどいと言うか、性能の問題がでるかも
- 422 名前：406 mailto:sage [2009/02/25(水) 00:45:53 ]
- >>419-
なるほど。別プロセスにすることも検討できそうです。
なんとなく雰囲気は分かりました。どうもありがとう。
- 423 名前：デフォルトの名無しさん mailto:sage [2009/02/25(水) 18:38:04 ]
- 処理毎に別プロセスって、昔の業務アプリみたいだな。っていうか、
今でもVBあたりでそんな開発やってそう。
1画面＝1exeファイルで、画面間はsystem()でプロセス呼び出し。
画面フォーム上で入力したデータ等は、ファイルに書き出して渡す。
大抵、exeファイルの名前は全部数字と意味不明なアルファベットで、
メモリ食いまくりで、やたらに遅い。(w
- 424 名前：デフォルトの名無しさん mailto:sage [2009/02/25(水) 19:28:47 ]
- 大規模なアプリはマルチプロセスの方が開発しやすいね
Windowsの場合は性能的にマルチタスクに向かないけど
- 425 名前：デフォルトの名無しさん mailto:sage [2009/02/25(水) 21:04:19 ]
- >>423
unixだとマルチプロセスは多いけどな。
VB6のアプリだとそういう作りになるのは仕方ない。
モジュール分割の手段がCOMしかない。
２０画面もあるとロードモジュールが１０M超える。
IDEに読み込んだりコンパイルするのにも一苦労。
プロセス間でDBのセッションを引き継げたらマルチプロセスでも軽くなるはずなのだけど、
それも出来ないからDBの接続でどうしても画面遷移が重くなってしまう。
- 426 名前：425 mailto:sage [2009/02/26(木) 01:19:09 ]
- >>424
マルチスレッドは、スレッド間のメモリ保護機構がないので、他スレッド
による破壊のリスクと引き換えに、高速なデータ共有が可能と思うが？
Windowsがマルチタスクに向かないとか、何を根拠に？
>>425
昔はメインメモリが少なく高価だったという事情もあるし、「unixだと」
という括りはどうかな？
20画面なんて、そんなに大きな規模なプログラムじゃないよね？その程度
の規模で単純にVBのソースだけなら、10MBを超えるようなことはないの
では？
確かにVB6当時のハード環境（Pentium 300MHz〜1GHz, メモリ64MB程度?）
でのビルドは遅かったかもしれないが、VBはVCよりは速かった様に記憶
しているけど？
それと、プロセス間でDBのセッションを引き継げないのは、VBや、Windows
に限定された話ではないのでは？
極端に処理が遅い業務アプリは、データベースの設計自体に問題があり、
無駄にDB間でレコードをコピーしたり、テーブルのリンクが必要だったり
ということが多い気がする。
- 427 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 01:55:03 ]
- プロセス間のデータ共有なら共有メモリがあるよ
特に親子関係があれば、mmap ANON とかでお手軽極楽
スレッドのメリットは（スレッド間なら）高速にディスパッチ出来る点だね
heap だろうとなんだろうとメモリは全部共有されるというのは
メリットでもあるけど、デメリットでもあるかな。
バグの原因になりがちだよね
- 428 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 03:45:35 ]
- 構造化されたデータを別プロセスと共有メモリ経由でやりとりするとして
c構造体ならまあなんとかなるんだが（いやそれでも大変だが）
c++クラスだとすんごいやりにくい
何かウマい方法あります？
受け渡し用にクラス作るのもアホらしいし・・・
変態的テンプレートでなんとかなるもんだろうか
それとも単なる通信バッファとしてしか使わない？
- 429 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 03:52:42 ]
- C++ならCの構造体も使えるんじゃ…。
- 430 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 04:07:16 ]
- そういうのはソケット使って単純化してる。
プロセス間共有メモリは後で環境や仕様が変わったときに
変更が大変だし流用も難しい。バグも入りやすい。
パフォーマンスを上げたいとか、よっぽどの理由でも
ない限り使われないんじゃないかな。
スレッドと違って>>428の言うデメリットもあるし。
ウマい方法はありません。
- 431 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 04:53:41 ]
- >>426
酷いミスリードだな。>424はマルチプロセスによるマルチタスクという技法がWindows向けでないと言っているように見えるが。
- 432 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 04:59:25 ]
- IE8はマルチプロセスですぜ
- 433 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 05:49:22 ]
- >>426
お前は誰なんだ
- 434 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 06:45:39 ]
- unixといえば今でもパイプをfork/execで分け合ってというイメージが強いな。
DBのコネクションは知らないがファイルハンドルならプロセス間で受け渡せる。
Windowsにもハンドルを複製して子プロセスに渡すオプションはあるのだが、
OS/2やNTは最初からスレッドをサポートしてたのであまり使われない。
- 435 名前：426 mailto:sage [2009/02/26(木) 17:42:01 ]
- >>425
ハンドルの複製に失敗しますた。orz 426=423です。
>>431
未だにWindowsがunixに劣っていると思っている原理主義者か、TRON房かも。
何を以ってunixを定義しているのか聞いてみたい。
>>434
ハンドルをコピーしたりは、MS-DOSにもあったかな。INT 28Hだか忘れたけど、
プリンタスプーラ用の割込使えば、一応擬似マルチタスクで一部のシステム
コールを呼べた。
デュアルコアやクァッドコアのCPUだと、マルチスレッド化すると理論上
2倍や4倍で動くと勘違いしているヤツもたまにいるよね。おまえのOSは
いったいいくつプロセスが動いていると思っているんだと、小一時間。(略
|
 |
