マルチスレッドプログラミング相談室 その５
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/09/10(日) 00:13:53OS・言語・環境は問わないが、それゆえ明記すべし。
その１ http://pc3.2ch.net/tech/kako/997/997345868.html
その２ http://pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ http://pc8.2ch.net/test/read.cgi/tech/1098268137/
その４ http://pc8.2ch.net/test/read.cgi/tech/1130984585/
0153デフォルトの名無しさん
2007/02/03(土) 09:49:270154デフォルトの名無しさん
2007/02/03(土) 10:21:080155デフォルトの名無しさん
2007/02/18(日) 16:38:41マルチスレッドは ム ズ カ ス ィ
0156デフォルトの名無しさん
2007/02/18(日) 20:05:23だまってmmapすればいいんでないの？
0157デフォルトの名無しさん
2007/02/18(日) 21:12:05お前にこの言葉を授けよう
「糞スレ立てるな」
0158デフォルトの名無しさん
2007/02/20(火) 23:27:340159デフォルトの名無しさん
2007/02/24(土) 10:27:57if文等で見に行くだけならぶつかることはないですか？
0160デフォルトの名無しさん
2007/02/24(土) 10:34:52最適化には気をつける必要があるが。
0161デフォルトの名無しさん
2007/02/24(土) 10:40:11読むだけなら排他不要。
ただしvolatileを忘れずに。
つーかvolatile最強。
0162デフォルトの名無しさん
2007/02/24(土) 12:17:45別スレッドからの書き込みも考慮するならロックなどによる同期が必要。
volatile はネタだよね？
0163デフォルトの名無しさん
2007/02/24(土) 12:46:430164デフォルトの名無しさん
2007/02/24(土) 13:02:150165デフォルトの名無しさん
2007/02/24(土) 13:16:54writerが一人、readerが複数ならロックする必要ないよ。
0166デフォルトの名無しさん
2007/02/24(土) 13:28:17あたまだいじょうぶか
0167デフォルトの名無しさん
2007/02/24(土) 13:28:40JavaやC#でのvolatileはその解釈であってる。
C/C++のvolatileは割り込みしか想定していないので、マルチスレッドでの動作は不定。
ただしシングルCPUでのマルチスレッドは割り込み(タイマー割り込み)で実現されているのでたまたま動作する。
>>165
変数がアトミックじゃない場合、例えば32bitCPUで64Bitの変数にアクセスする場合などは、
書いてる最中に読み込みされると半分しか書き換わってない状態を読み込む可能性がある。
0168デフォルトの名無しさん
2007/02/24(土) 13:34:19ＣＰＵキャッシュの問題は難解だね。
さらにウィークメモリモデルともなるとさすがについて行けんorz
0169デフォルトの名無しさん
2007/02/24(土) 13:43:290170デフォルトの名無しさん
2007/02/24(土) 16:37:410171デフォルトの名無しさん
2007/02/24(土) 16:41:40#いや、intでも排他するべきなのかもし煉瓦。
0172デフォルトの名無しさん
2007/02/24(土) 18:52:05> #いや、intでも排他するべきなのかもし煉瓦。
というのが>>168だね
マルチCPU環境の排他はバス設計の影響もうけるから
環境を明記しないと言及不能やね
0173デフォルトの名無しさん
2007/02/24(土) 20:21:33書き込みがアトミックに出来るのに、読み込みがアトミックに出来ない、なんて
変態CPUが現存するのか？そういうCPUではロックをどう実装するんだろ？
0174デフォルトの名無しさん
2007/02/24(土) 23:09:380175デフォルトの名無しさん
2007/02/25(日) 01:29:43＞変態CPUが現存するのか？
＞書き込み側が明示的に、アトミック書き込み命令を出せばいいんでね？
↓
＞読み込みもアトミックじゃねーと意味ね-よ
だれも読み込みがアトミックにできないなんて言っとらんわ。
0176デフォルトの名無しさん
2007/02/25(日) 04:26:18＞ねーと → ー
＞ね-よ → -
この不整合の方が気になるな
どちらかがアトミックじゃないのかもしれない
0177デフォルトの名無しさん
2007/02/25(日) 05:04:120178デフォルトの名無しさん
2007/02/25(日) 15:04:490179デフォルトの名無しさん
2007/02/25(日) 15:39:00volatile無意味説
0180デフォルトの名無しさん
2007/02/25(日) 17:24:44「お母さんが駄目って言ってたから」レベルの話しか書いてないな。
そして、そのURLを貼る>>179も同様。
0181デフォルトの名無しさん
2007/02/25(日) 17:50:330182デフォルトの名無しさん
2007/02/25(日) 18:59:13http://www.ddj.com/dept/cpp/184403766
0183デフォルトの名無しさん
2007/02/25(日) 19:32:05もしかして >>181 へのレスのつもりなのか？
0184デフォルトの名無しさん
2007/02/25(日) 19:41:48"Paradoxically, it's worse to use volatile directly with built-ins, in spite of the fact that initially this was the usage intent of volatile!"
0185デフォルトの名無しさん
2007/02/25(日) 20:20:26これって
＞スレッドセーフなメソッドにはvolatileをつける。
という提案だよな？まだ実装はないと思ったのだが。
0186デフォルトの名無しさん
2007/02/25(日) 22:48:590187デフォルトの名無しさん
2007/02/25(日) 23:35:03実装ってどういうこと？標準 C++ コンパイラがあれば使える手法に見えるんだけど。
0188デフォルトの名無しさん
2007/02/26(月) 01:31:15プティマイザがレジスタキャッシュしないように指示するために導入された物で,
バリア同期命令とか生成する処理系は皆無のような気がするが...
俺の認識が古くって, バリア同期とか生成してくれる処理系が既にあるんだった
ら先にあやまっとく
0189デフォルトの名無しさん
2007/02/26(月) 05:30:32簡単な例で言えば
(タイマ割り込み等で更新される)カウンタを読む場合とか
複数スレッドで値を読み取るとしても、ロックする必要なんか無い。
たとえ1ns更新が遅れたって、問題が出ることは無い(問題が出るようなら、設計がおかしい)。
え、更新時の再入を考慮しろって？
そういうのを「設計」と言うんだろうに。
0190デフォルトの名無しさん
2007/02/26(月) 06:29:25int func() const { } はよく使うが、int func() volatile { } を実際に使ってる例ははじめてみる。
ただその記事のLockingPtrは func() volatile の仕組みだけ拝借して実際の排他はmutexでやってるようだ。
よく理解できない部分もあるがvolatileしておいてconst_castで限定的に穴あけてるのだろうか。
このスレで問題になるのはそこではなくて、
記事の最初と２番目のコードで while (!flag_) のflagがvolatileだけでいいのか、
同期機構を使わなくてはいけないかのポイントだと思う。
0191デフォルトの名無しさん
2007/02/26(月) 07:52:54volatileで済むってのは、コヒーレントキャッシュを持っている環境で
アトミックに読み書きできるサイズ限定だから、メモリバリアは関係ないよ。
2つ以上の変数に依存関係があったら、volatileだけでは無理。
一般論の話をすれば、キャッシュの一貫性を保障しない環境もあるから
int程度でもvolatileでは駄目という話になるが。
0192デフォルトの名無しさん
2007/02/26(月) 09:15:17constみたいな印としてvolatileを使ってみようっていう提案だよね？
0193デフォルトの名無しさん
2007/02/26(月) 19:26:29処理系を指定しないでvolatileについて語れることはない
0194デフォルトの名無しさん
2007/02/26(月) 21:25:32漏れだけではないはずだ
0195デフォルトの名無しさん
2007/02/27(火) 00:02:42>>191
一貫性を保証しなかったとしても、それはあくまで保証の話。
いつまで経っても同期されないような腐ったCPUってあるの？
あったとしたら処理系としてBrokenだよなぁ・・・。
>>193
ここに書いてる人のほとんどは処理系依存だなんて承知の上でしょ？
とりあえず、intだとしても同期やメモリーバリアは必要か？
って問いはもう少しレベル分けした方がいいと思う。
1. 読み込みに依存した書き込み(read-modify-write)
⇒ 同期もしくはメモリーバリアを含んだCASが必要。
2. 読み込みに依存しないが、確実に更新を見る必要がある
⇒ OoOを回避するために、少なくともメモリーバリアは必要。
3. 読み込みに依存しないし、更新は近いうちに反映されればよい
⇒ volatileでレジスタへの張り付きを阻害するだけで問題なし？
>>189の「更新が遅れても構わない」は3になると思うんだが。
0196デフォルトの名無しさん
2007/02/27(火) 01:19:13進捗を書き込むのを処理スレッドに限定してGUIスレッドでそこをvolatileで参照するのもありってことでOK?
0197デフォルトの名無しさん
2007/02/27(火) 01:57:30環境を限定しない討論に何の意味もないって感じだな。
0198デフォルトの名無しさん
2007/02/27(火) 03:01:550199デフォルトの名無しさん
2007/02/27(火) 08:43:30> とりあえず、volatileをCの最適化阻害だけと仮定して、
曖昧な仮定だな。
まずはお前の想定している処理系と、そのマニュアルにある
volatile参照の仕様を書くんだ。
0200デフォルトの名無しさん
2007/02/27(火) 09:11:34template <typename T>
struct NativeWrapper
{
operator T&() { return obj; }
private:
T obj;
};
volatile NativeWrapper<int> syncint;
mutex mtx;
LockingPtr<NativeWrapper<int> > pInt(syncint, mtx);
*pInt = 10;
0201195
2007/02/27(火) 12:18:08そんなとこ。他ではTwo-Phase Terminationの終了フラグとか。
こちらの場合はメモリーバリアを含んだ同期をループの内部で
実行する事が殆どだから、次のループで確実に気付くだろうけど。
>>197,199
おまえら処理系依存って書きたいだけだろ？
実際のとこはどうなのか、って話がしたいんだよ。
少なくともOoOやコヒーレンシが問題になるんだから、
最低限SMP/Multi Core/HT等のアーキテクチャとなる。
例えばIA-32,Power PC,Sparc等のSMPの類をサポートした
アーキテクチャのうち、>>195よりも厳しい制約が必要と
なるものは存在するの？
0202デフォルトの名無しさん
2007/02/27(火) 13:04:58個々の CPU について考えるなんて面倒だから、
保証されてるかどうかで話したほうが楽なのに。
今は無くても将来にわたって無いとも言えないしね。
0203デフォルトの名無しさん
2007/02/27(火) 14:04:14データ構造上の都合か何かでキャッシュラインをまたぐような位置から
int を読み込む場合には 3 もだめじゃないかな。
0204デフォルトの名無しさん
2007/02/27(火) 14:12:43Intel Itanium では、非共有キャッシュが大きい上にキャッシュフラッシュの順序が
書き込みの順序と異なる。ので、
・volatile int a を監視
・aが変更されたら「何か」を行う
という処理の場合、大抵は「何か」の準備が出来たから a を1にしてるんだと思うけど、
メモリバリアが無いとその準備の処理結果を読み出せない可能性がある。
例） volatile size_t buflen; volatile char buf[max_buf]; で、
スレッド1: buflen = read(hoge); ...
スレッド2: if (buflen>0) { bufを利用; }
で、（スレッド2側のCPUから見て）buflen には read の結果のバイト数が書かれているが、
buf の内容はデタラメ、という状況がごく当たり前にあり得る。
0205195
2007/02/27(火) 14:54:42キャッシュラインをまたぐ場合って、普通のコードじゃ起きないし、
char buf[sizeof(int)+1]; *(int *)(buf+1) = 0;した場合とかでしょ？
今では例外飛ばさずにアクセスできるアーキテクチャの方が少数派なのでは？
>>204
他の変数を確定的に見る必要がある場合はOoOの関係で無理。
>>195はひとつのintを扱う場合なつもりで書いてます。
>>196を例にすると、タイマでプログレスバーを更新する時はvolatileのみ、
最後に終了したかを確定的に判断したい時だけpthread_join()するケースとか。
0206デフォルトの名無しさん
2007/02/27(火) 15:21:57PCで使われているCPUの98%は、それをごく普通に実行します。
任意位置からの32bitの整数読み出しはMPEG系のビデオコーデックの
処理では多利用されるし。
0207195
2007/02/27(火) 16:11:02そんな下らないツッコミは要らないって。。
Codecの処理だろうが、境界整列に反したメモリアクセスなんて
行儀の悪いコードなんじゃないの？少なくともポータブルじゃない。
処理系依存のレベルで言ったらvolatileの比じゃないと思うんだけど。
0208デフォルトの名無しさん
2007/02/27(火) 16:25:35漏れは何も言っていません。
実存するシステムの大半では割合で例外は飛ばないという
（関連する）別の事実を提示しただけですよ。
0210デフォルトの名無しさん
2007/02/27(火) 19:55:55実際の例で言うなら、MPEGのシステムストリームから4バイト長さの整数を取り出すとき、
ポータビリティを重視している ffmpeg ではバイト単位で取り出して整列してますし、
IA32/64が前提のIPPではポインタをそのままデリファレンスしてアライメントを気にせずに整数を取り出してます。
「普通のコードじゃ起きないし、例外飛ばさずにアクセスできるアーキテクチャの方が少数派」だから、
キャッシュラインまたぎの問題は無視してよいとでも言いたげな感じですが、
実際のとこどんなプログラムをどれだけ調べた上で書いてるんですか？
0211デフォルトの名無しさん
2007/02/27(火) 20:59:04アトミック書き込みはできない。
0212デフォルトの名無しさん
2007/02/27(火) 21:54:58実装の詳細じゃなくてアーキテクチャの視点で語ってほしいです><
0213デフォルトの名無しさん
2007/02/27(火) 22:12:28メタ論がやりたいならどっか適当にスレ立てろよ
これがほんとにマルチスレッド
0214デフォルトの名無しさん
2007/02/27(火) 23:34:05intでもアトミックに読めないとか、そういう問題とは別次元だろ。
0215デフォルトの名無しさん
2007/02/27(火) 23:35:070216195
2007/02/28(水) 01:26:31>>209は自分じゃないんで・・・。
他の方も書いているように、CodecみたいにCPUベタベタな
最適化を行う場合を考えてもしょうがないかと。
今のところは>>189や>>196みたいなケースの場合にvolatileで
不十分な証拠は(処理系依存を除いて)出ていないんじゃないですか？
そんなわけで、今のところ>>180から進展はなさそうに思います。
>>213
自分はPCサーバクラスで使われるCPU辺りをメインに書いてます。
今はノートですらDual Coreだったりするので、その辺りも含めて
昔で言うワークステーションクラスまででしょうか。
0217デフォルトの名無しさん
2007/02/28(水) 02:53:24「あぁそうだといいね」とも思えるが、場合によってはロックが必要なことは
理解しているようだし。そうなると細かいこと考えずに全部ロックしとけば
いいと考えそうなもんだ。
なんでそんなに必死になってまでロック使いたくないの？
わざわざ保証されてないコード書くメリットが何かあるの？
0218デフォルトの名無しさん
2007/02/28(水) 06:28:24結論はそうなんだけど、そこに至る過程を検証したいというのも分からないではない。
mutexの中の人が何をやっているかとか、実際身近にあるＰＣで賢い小人さんがどう働いているかとか、
そういう話題なら問題は無いだろう？
0219デフォルトの名無しさん
2007/02/28(水) 13:20:29>なんでそんなに必死になってまでロック使いたくないの？
実行コストに決まってるだろ。
実行コスト無視できるなら、スピンロック、read-writeロック、プロセス内Mutex、プロセス間Mutex、
の使い分けなんて必要ない。
ただ、volatileで生成されるコードと、他のロックでどちらがコストが高いかは知らん。実行系によるし。
0220デフォルトの名無しさん
2007/02/28(水) 13:51:461)変数のレジスターへのキャッシュ。
2)コンパイル時の命令の並び替え。
3)CPUによる命令の並び替え(out of order)
4)CPUキャッシュ間の非同期。
1,2はコンパイラの仕事。
3は単一CPUでは発生しない。マルチCPUでは両方のケースがある。
4は単一CPUでは発生しない。マルチでもコヒーレント(一貫性)が保障されている処理系が多い。
3,4が発生しないでメモリー更新の順番が正しく見える構成をstrong memory orderと呼ぶ。
volatileだと1,2でかつアトミックな操作ができる単独の変数のみ。
メモリバリアは1,2,3,4すべてを満たしていて、
同期系のファンクションを使えばメモリバリアは適切に適用される。
書き込みが１スレッドで多数の読み込みスレッドがある場合に通常のLockが負荷が高いようなら、
ReadWriteLockとかInterLockとかそういったものを検討すべきだろう。
0221デフォルトの名無しさん
2007/02/28(水) 13:57:54＞いつまで経っても同期されないような腐ったCPUってあるの？
＞あったとしたら処理系としてBrokenだよなぁ・・・。
ないとは言い切れない。互換性、安全性をとるなら同期ファンクションを使っておこう。
windowsXPまではstrong memory orderを前提にしているらしい。
MSDNのvolatileの説明が変なのはこのためだろうか。
移植性を無視してターゲットを絞るなら独自にいろいろやるのもありかもしれないが、
windows2003(今のところItanium用だけらしいけど)からは上記の3,4があるweak memory orderも
視野にいれているらしいから、こういうヴァージョンアップ時に困るな。
0222デフォルトの名無しさん
2007/02/28(水) 17:09:18（そもそもCPUがマルチプロセッサ用に作られていない）
そういう環境にマルチスレッド対応のOSが移植されてるかは、
ググってみたが見つからなかったな。
一昨年あたりから、組み込み用CPUでもキャッシュ同期メカニズムを
持った物が出てきたようで、SMP対応のlinuxが移植されてたりするけど。
0223195
2007/02/28(水) 17:27:11ほぼそんなとこです。
あとは、なんでPOSIX ThreadsにCASがないのか、とかね。
プリミティブ志向な設計なんだから追加されてもいいのに。
有名どころのアプリのいくつかは自前で実装してたりするし。
>>221
そりゃないとは言い切れないでしょ。
でもそういうのって、二の補数表現や1byte=8bitを仮定して
プログラムを書くのは良くないってのと同じなんじゃないの？
1word=36bitみたいな変態アーキテクチャを相手するのと一緒。
0224デフォルトの名無しさん
2007/03/01(木) 00:19:15子スレッドの処理が止まっているとき、終了する方法が知りたいです。
-----------------------------------------------------------------
//子スレッドの関数
void thread_func(){
//Sleep();やソケットのaccept関数など永久に待つ関数などで、
//処理が止まっているので終了状態になりません
}
//子スレッド呼び出し
thread_id = _beginthread(thread_func,0,(void *)param)
//終了処理
GetExitCodeThread( thread_id,lpExitCode );//終了コード取得
ExitThread(lpExitCode );//終了コード指定して終了
CloseHandle(thread_id);//ハンドル閉じる
-----------------------------------------------------------------
１、子スレッドのsleep、accept関数など待ち状態を、解除する方法あるでしょうか？
処理が進めば、_endthreadで終了することが出来きるのですが。
２、強制的に親スレッドから、安全に子スレッドを強制終了する方法あるでしょうか？
_beginthreadは、CreateThreadを呼んでるみたいなのですが、上記のように
"//終了処理"しても大丈夫でしょうか？安全な方法教えていただけないでしょうか。
よろしくお願いします。
0225デフォルトの名無しさん
2007/03/01(木) 00:19:22なんで良くないと言われていることをわざわざやりたがるの？
0227デフォルトの名無しさん
2007/03/01(木) 01:06:04最近のレスでロック API の仕様の根拠となるものはあらかた提示されたんじゃないの？
0228デフォルトの名無しさん
2007/03/01(木) 01:22:09とりあえず、
・必要なら、子スレッドでは極力タイムアウトするAPIを使う
・_beginthread()の場合、スレッド関数の戻りで子スレッドのハンドルは自動開放されるので
明示的に開放する必要はない
・少なくとも_beginthread()のハンドルにCloseHandle()を使うのは間違い
きちんと対応する関数をセットで使わなければいけない
・ただ、親スレッドでExitThread()したら、その後のCloseHandle()は実行されないよ
・子スレッドの安全な中断方法はない。
突っ込み所満載すぎるので、MSDNなりナニなりよく読むべし。
0229デフォルトの名無しさん
2007/03/01(木) 03:23:13タイムアウト処理を考えるという方針でいきたいと思います。
sleepは時間を短くすればいいですし、
acceptは、selectを使ってrecvのタイムアウト関数（timeoutRevcとします）
と同じにすれば、timeoutAccept関数作れるかもしれないです。
・timeoutAccept抜けたら、はじめの一回目は、ソケットが読み込めるのわかってるので普通のrecv関数を呼ぶ。
・次の受信から、timeoutRevc呼ぶ感じでしょうか。
いくつも箇条書きでアドバイス、ありがとうございました。
0230デフォルトの名無しさん
2007/03/01(木) 07:04:23acceptする前に、select関数使えないんでしょうか。
FD_ZERO(&readfds);
FD_SET(soc,&readfds);
select(width,&readfds,NULL,NULL,&timeout)
socは、きちんと渡せていたんですが、接続試しても
select抜けられずに、全部タイムアウトになります。
accept呼んでからじゃないと、ソケットの読み取り可能か
わからないかもです。
スレ違いになりますので、ネットワークのスレに行きたいと思います。
ありがとうございました。
0231デフォルトの名無しさん
2007/03/01(木) 11:14:25「volatileが最強でない環境って存在するの？」
「現存しないからvolatile最強ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」
>>161 でFA出てるしｗｗｗ
0232デフォルトの名無しさん
2007/03/01(木) 11:18:500233デフォルトの名無しさん
2007/03/01(木) 12:28:10で聞いてたんだが、此処で聞いた方が良いかと思ったので、
再質問させてもらいます。
Windows MFCでマルチスレッドは止めておいた方が良い
と、良く聞くんだけど、具体的にどんな問題が発生するのか
掲示しているところが無いんだけど、どうしてMFCでの
スレッドは嫌われるのか教えてもらえないでしょうか。
単なる好奇心なので、仮説でもうれし。
0234デフォルトの名無しさん
2007/03/01(木) 12:42:430235デフォルトの名無しさん
2007/03/01(木) 12:48:10それま色々なスレで同じ質問をしないほうが良いと言われただけでは？
0236デフォルトの名無しさん
2007/03/01(木) 12:50:14とりあえず移動元に誘導書いておけよ、マルチ扱いされるぞよ。
俺も聞いたことない。
0237デフォルトの名無しさん
2007/03/01(木) 13:27:040238デフォルトの名無しさん
2007/03/01(木) 14:21:410239デフォルトの名無しさん
2007/03/01(木) 16:05:38つ http://support.microsoft.com/kb/254956/
0240233
2007/03/01(木) 16:17:27>MFC のシステムそのものがマルチスレッドに向いていない。
ttp://www.kab-studio.biz/Programing/PragmaTwice/Main/292.html
さすがにどこで見たかを思い出せなかったので検索して
出てきたのが例えばこれとか。
>>236
>>237
移動元に書いてきたよ。
ごめんよ。
0241デフォルトの名無しさん
2007/03/01(木) 17:05:31WaitForSingleObjectで待つんじゃなくて自イベントで通知
MFC関係なくないか？
読みづらいし会話式がアレだな
0242デフォルトの名無しさん
2007/03/01(木) 17:17:57ワーカースレッドについては特にMFC特有の問題じゃないな。
0243デフォルトの名無しさん
2007/03/01(木) 18:03:52じゃあ、そのサイトが間違い。
いや間違いというか、MFCがマルチスレッドに対して便利な機構を用意しているかというとNoだけど、
マルチスレッドを意識してないわけじゃない。つまり、ユーザーからロックできないグローバル変数、
クラス変数はロックしてる。
なんで、ユーザーからロックできる部分については、勝手にロックして、スレッドセーフにしろよ、
ってスタンス。それを「向いてない」と表現するかどうかは人による。
・MFCとマルチスレッドの関係 (Afx...でのMFCグローバル情報へのアクセス等)、
・Win32とマルチスレッドの関係 (SendMessageがらみのウィンドウループの把握、WinSockでのWM_を使った非同期処理等)、
・一般的なGUIシステムにおけるマルチスレッドの作法 (GUIスレッドを止めない、長時間処理は別スレッド、非同期化等)
を分けて考えるべき。
0244デフォルトの名無しさん
2007/03/01(木) 18:24:21Wikipediaに書かれるほど挫折した連中に嫌われているってことだな。
0245デフォルトの名無しさん
2007/03/01(木) 18:47:00「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？
「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。
>まぁMFCはガベコレがないという致命的欠点を持っているなんて
これは笑いどころですか？
0246243
2007/03/01(木) 19:03:59>「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？
>「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。
いや、俺に言われても。
0249デフォルトの名無しさん
2007/03/01(木) 21:02:370250デフォルトの名無しさん
2007/03/01(木) 21:11:36改行位置のせいで勘違いするのも分からんでもないが。
0251デフォルトの名無しさん
2007/03/01(木) 21:27:350252デフォルトの名無しさん
2007/03/01(木) 22:08:15| | /, −､, -､ｌ /､ ヽ
| _| -| ･|< || |･ |―-､ |
, ―-､ (6 ＿ｰ っ-´､} ｑ -´ 二 ヽ |
| -⊂) ＼ ヽ_ ￣￣ﾉﾉ ﾉ＿ ー | |
|￣￣|／ （_ ∧￣ / ､ ＼ ＼.￣｀ | /
ヽ ｀ ,.| ￣ | | O＝＝＝＝＝ |
｀− ´ | | ＿| / |
| （t ） / / |
「>1からマークスイープでGCするよ！」 「コンパクションも忘れずにね」
１時間後…
,-――-､ ＿＿＿
{ , -_−_− ／ _ _ ヽ
.(6（ /),(ヽ| / ,-（〃）bヾ）､l
／人 ー- ソヽ ＿ | /三 U |~ 三|_
／ / | ￣_∧／ ヽ |（__.）―-､_|＿つ_）
| | ＼/_/-､ / / /｀ー--―-´ /
|-＼ _|_ ）＿| / | //￣（ ｔ ）￣/
ヽ-|￣| |＿|_ / ,− | | ヽ二二/⌒l
／ l―┴､|＿＿) | （＿＿＞ -―（＿ﾉ
／ ｀-―┘ / ｀- ´
/
「>1しか残らなかった…」 「テンプレへのリンクもなかったのか！」
■ このスレッドは過去ログ倉庫に格納されています