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

マルチスレッドプログ ..

217:デフォルトの名無しさん
08/12/02 13:11:00
日本語でおｋ

218:デフォルトの名無しさん
08/12/02 13:27:51
やっぱり際どい領域を原子的に相互排他する場合
反応時間が長い記憶装置を直接読み書きするのは非効率だから
トランザクショナルメモリみたいな遅延する仕組みがどうしても必要じゃないですかね

トランザクショナルメモリだけはどうにもならんかった。

219:デフォルトの名無しさん
08/12/02 13:37:44
「処理単位記憶装置」かな？

220:デフォルトの名無しさん
08/12/02 14:44:45
都覧公国量産型六番書鳴記憶

221:デフォルトの名無しさん
08/12/02 20:55:12
ザクメモリってどうやってつくるの？
アルゴリズム全然解らん

222:デフォルトの名無しさん
08/12/02 21:45:47
弱そうなメモリだな

223:デフォルトの名無しさん
08/12/02 21:51:07
トラングフショナルメモリ

224:デフォルトの名無しさん
08/12/02 21:51:07
トランザクショナルメモリって
どんなアルゴリズムなのですかね？

何処探してもみつからない

225:デフォルトの名無しさん
08/12/02 22:02:31
ロックフリーあたりで調べればいいと思う
でもコストが大きい気がするのでリードライトロック程度で十分かと

226:デフォルトの名無しさん
08/12/02 22:14:10
リードライトロックの中にもフェアかフェアじゃないかで変わるけどね。
オブジェクト指向はハードウェアの都合までは吸収してくれんよなぁ。
マルチスレッドのデザパタ見ててそう思う。

227:デフォルトの名無しさん
08/12/02 22:44:09
排他制御書き込みって
pthread_rwlockで実現できますか？

228:デフォルトの名無しさん
08/12/03 00:04:59
素直にmutexつかっとけ
読み書き両方な

229:デフォルトの名無しさん
08/12/03 00:17:05
>228
排他制御書き込み実現しようとすると
pthread_mutexでは、try_lockを全mutex分
毎回ぶん回すってことでおｋなのかな？

この辺の定石ってよくわからん

230:デフォルトの名無しさん
08/12/03 03:01:55
mutexが複数あるの？
どういう排他制御をしたいのかわからん

231:デフォルトの名無しさん
08/12/06 15:29:07
スレッド2000個作って
画像データダウンロードするやつ作ったんだけど
スレッドが全部同時に動作しないんだ
どこがいけないんだ？

232:デフォルトの名無しさん
08/12/06 15:42:50
当てずっぽうだけどサーバが2000接続も同時に処理できないんじゃね
1個ずつ順番に処理して残りは待たされてるとか

233:デフォルトの名無しさん
08/12/06 15:53:38
そもそも2000スレッドが同時に動くはずがない。

234:デフォルトの名無しさん
08/12/06 15:58:58
1000コア*2(HT)ですね
もしそんなのがあったとしても現状Linuxしか動かせない

235:デフォルトの名無しさん
08/12/06 16:25:36
「全部同時に」ってのがどの程度の同時性を指してるんでしょうね

236:デフォルトの名無しさん
08/12/06 18:00:38
Sunのやつなら動くと思うよ

237:デフォルトの名無しさん
08/12/06 19:34:10
どの程度とかの精度の問題ではないんですよ
動けばいいだけのレベルなんですけど
for　ループ内で約2000 個のスレッド作るんで、
タイミング的にはほぼ同時な気がしますが
OSにもよるかもしれませんが、
そうそう１０秒以上も差が出るとは思えないんで
精度は１０秒以内くらいの超おおざっぱでいいですけど
動かないんですよ

ちなみにCUI コマンドプロンプトで多数のスレッドから
printf されるとやはり多重に出力され
hogehogehogehoge　が
hohohogegegehoge　になったりするんでしょうか？

238:デフォルトの名無しさん
08/12/06 19:34:15
環境は？
win32じゃなさそうだが

239:デフォルトの名無しさん
08/12/06 19:45:36
Erlangなら60000スレッドぐらい起せるよ

240:デフォルトの名無しさん
08/12/06 19:54:33
>>237
標準出力はバッファリングされるので、混ざる場合はバッファサイズずつ混ざる。
>237のように1バイトずつ混ざることはない。

241:デフォルトの名無しさん
08/12/06 22:34:02
>>237
動かないってどう動かないんだよ。

242:デフォルトの名無しさん
08/12/06 22:45:56
>>238
機密事項なので書けません＞＜

243:デフォルトの名無しさん
08/12/06 23:39:13
おれも1万個ぐらい動かしてるけど別に問題ないな。
機密事項だから環境は書けないが。

244:デフォルトの名無しさん
08/12/06 23:53:58
＞スレッド2000個作って画像データダウンロードする
あほのすることだな

245:デフォルトの名無しさん
08/12/07 05:05:46
>>244
ネットワークモニタの使用率が25%超えたことないんで
限界までいどみたかったとです

246:デフォルトの名無しさん
08/12/07 05:36:11
>>245
自分で対向サーバを用意すれば簡単だよ。

247:デフォルトの名無しさん
08/12/07 06:44:22
スレッドって関係あるん？

248:デフォルトの名無しさん
08/12/07 07:44:39
>>247
deteike

249:デフォルトの名無しさん
08/12/07 10:16:03
2000個もスレッド作ってりゃオーバーヘッド大きすぎてそりゃ限界までいかんわな。
っていうかそもそもネットワークモニタって実効速度の％出してくれるんだっけ？？

250:デフォルトの名無しさん
08/12/07 11:04:38
>>249
タスクマネージャにあるよ

OSの限界ギリギリまで性能を出そうとしたのに
なんてOSだ・・・

251:デフォルトの名無しさん
08/12/07 11:48:23
馬鹿は巣にお帰りください。

252:デフォルトの名無しさん
08/12/07 15:04:34
だからなんでスレッドにすると帯域使用量が上がるんだっけ？
でっかいファイル一つを read するのと、スレッド2000個で read するので
差が出る理由はなに？

253:デフォルトの名無しさん
08/12/07 15:06:38
ネットワークの話じゃなかったのか。

254:デフォルトの名無しさん
08/12/07 15:19:33
ああ、そういうことね
1スレッドひとつにつき１つの画像をダウンロードするプログラムを組んだ
このスレッドを2000個同時に実行したけど
2000個同時（プログラム的には）には動作してくれなかった
ということ

255:デフォルトの名無しさん
08/12/07 15:47:41
だから、2000ポート空けて待つような対向サーバを自前で用意しろって。

256:デフォルトの名無しさん
08/12/07 16:10:56
>>252
思い込み

257:デフォルトの名無しさん
08/12/07 16:25:13
>>250
だからさあ、例えばギガビットイーサだったら100%って1Gbpsじゃないの？
実効速度250Mps出てても25%だぜ？

258:デフォルトの名無しさん
08/12/07 20:02:19
バス速度的に実際1Gbpsなんて無理
100Base-TXで考えなさい

259:デフォルトの名無しさん
08/12/07 20:07:35
FPGAのNICなら１Ｇっていったら１Ｇ出ますが？

260:デフォルトの名無しさん
08/12/07 20:08:02
うん
馬鹿は帰れ

261:デフォルトの名無しさん
08/12/07 20:11:23
>>254
そもそも、シングルコア、1スレッドあたりのタイムスライスを10msとすると、
1周するのに単純計算で10ms×2,000=20,000ms=20秒だ。実際には10msよりも
もっと長いのが普通(※1)だし、スレッド切り替えにもコストがかかる(※2)し、
マルチコアとしてもコア数分の1にしかならない上に、コア間の調停にも
やっぱりコストがかかる(※3)。
あと、ネットワークの実効速度についても、デカいパケットが順番に流れる
なら、かなり帯域上限に近付けることができるが、細かいパケットが非同期に
衝突しまくりながら流れるようだと、いいとこ1/3くらいしか出ない。

ぶっちゃけ、アプローチが間違ってるとしか思えん。

※1:ぐぐってみたところ、Windowsについてはこんなんが引っかかった。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
もっと良い資料やUNIXについての言及があれば教えてくれ。
※2:レジスタ等のコンテキスト情報を全部保存してパイプラインを捨てて
他スレッドのコンテキストを読み込む。キャッシュから溢れてたら最悪
メインメモリまで取りに行くハメになるぞ。
※3:各コアが互いに読み書きできるレイヤまでデータが届く必要があるため。

262:デフォルトの名無しさん
08/12/07 20:37:21
たしか一般に、CPUサイクルで見て、
スレッド作成が数万～10万サイクル（ひょっとすると数十万～だったかも）、
コンテキストスイッチが数千～1万サイクル
とか見た気がする。

263:デフォルトの名無しさん
08/12/07 20:38:37
おっと、スレッドに関わるオーバーヘッドの話ね。

264:デフォルトの名無しさん
08/12/08 01:15:52
>>262
＞コンテキストスイッチが数千～1万サイクル

今時LinuxでもO（1）スケジューラなわけだが。

265:デフォルトの名無しさん
08/12/08 01:22:44
そりゃ的外れなレスなこって

266:デフォルトの名無しさん
08/12/08 01:48:56
ﾜﾛﾀ

267:デフォルトの名無しさん
08/12/08 09:39:27
WindowsとかLinuxとか・・・
そんな貧乏臭いOSの話ばっかでワロタ

268:デフォルトの名無しさん
08/12/08 10:27:54
そうですか

269:デフォルトの名無しさん
08/12/08 13:48:37
アセンブラ級はついていけｎ

270:デフォルトの名無しさん
08/12/08 18:58:28
何十万ものスレッドをサポートするようなシステムもあるんだよね？

どういう構造になってんだろ
根本的に考え方からちがうのかな？

271:デフォルトの名無しさん
08/12/08 19:01:51
>>270
カーネルスレッドは使わない（ユーザスレッドでやる）、か、そういうスレッドを
サポートしたカーネルでないと無理。普通のUnixの普通のカーネル（含むLinux）
とかだと無理。

272:デフォルトの名無しさん
08/12/08 21:55:16
OSはWindowsXPなんですよ
で、ソースですが
for(　int　i=0;　i<2000;　i++　)
{
　　_beginthred(　DoIt,　0,　NULL　);
}

void　DoIt(　void　*　)
{
　　DownloadURL(　URL,　filename　);
　　_endthread();
}
ってな感じですけど
ほとんど同時時間にスレッドを起動させてるのですが、
タイムスライスが各スレッドに割り当てられないのでしょうかね？

それともやっぱり　>>232　さんの言っているように
サーバー側が延滞処理をほどこしているんでしょうかね？

問い合わせたくてもあまり進んで聞けるようなことではないので

273:デフォルトの名無しさん
08/12/08 22:05:16
>272
スタック用の仮想メモリが足りなくなってない？

あるいは、その呼んでいるDownloadURLが
STAみたいな実装とかｗ

>261
IOが支配的なスレッドで、タイムスライスの意味なんか
ほとんどないとおもうけど。

274:デフォルトの名無しさん
08/12/08 22:48:50
同一サーバにHTTPコネクションを2000張ろうとしていたオチと予想

275:デフォルトの名無しさん
08/12/08 23:28:21
Irvineとかで試してみればどうかな

276:デフォルトの名無しさん
08/12/08 23:41:31
>>274
攻撃とみなされても仕方ありませんな

277:デフォルトの名無しさん
08/12/09 00:06:27
>>273
仮想メモリなのに足りなくなるとは、これいかに。

278:デフォルトの名無しさん
08/12/09 00:15:39
2000個のスレッドでスタックだけで仮想メモリ使い切るだろWin32なら。

279:デフォルトの名無しさん
08/12/09 00:20:56
いくらIOバウンドだって普通2000はやりすぎ。
普通はせいぜい100までだろう、CPU数にもよるがそれでも多いくらいだろう。
だいたい2000個の各ファイルのサイズはどのくらいで、
単体での転送速度はどのくらいなんだ。

ってダウンロードが2個までしか同時に動いてなかったりしてなｗ

あとサーバ側も普通は当然そんなに同時処理できない
キューに入って順番に処理されるだけ。

280:デフォルトの名無しさん
08/12/09 01:06:30
>>278
> 2000個のスレッドでスタックだけで仮想メモリ使い切るだろWin32なら。

相変わらず意味不明。

281:デフォルトの名無しさん
08/12/09 01:07:09
俺がワーカスレッドをプールする場合は、
特に深く考えずに単にコア数の倍だけ用意しとく。
IOブロックで動けるようになった他のスレッドもIOでブロックされるだけだしね。

282:デフォルトの名無しさん
08/12/09 01:23:17
>277,280
正確には仮想メモリ空間。
Win32では、ふつー、プロセス毎に、ユーザ空間として
使用可能なのは、下位から7fffffffあたりまでで、2GB。
だいたい、ポインタが32bitであることの限界とみていい。

で、Win32のスレッドは、１つあたり、規定では1MBの
スタックを仮想メモリ空間に確保する。他にもDLLとかの
コード領域も同じ2GBの空間を使うわけで。

283:デフォルトの名無しさん
08/12/09 01:35:04
>>282
仮想メモリというのはプロセス毎にあってだな・・・

284:デフォルトの名無しさん
08/12/09 01:47:50
>>283
>237嫁

285:デフォルトの名無しさん
08/12/09 01:56:53
>>283のおバカさを示すなら>>191の方が適切だろ。

286:デフォルトの名無しさん
08/12/09 09:08:47
>>281
だったらコア数の2倍はちょっと少なくない？
まあIOってもネットワークなどの場合で、
もちろん少ない投入数で帯域使いきれるような場合や
同一サーバにつなぐような場合は別だが。

287:デフォルトの名無しさん
08/12/09 10:26:51
Win32(笑)

288:デフォルトの名無しさん
08/12/09 10:28:16
ネイティブなプロセスやスレッドで並列性増やす方法は全然スケールしないから
軽量プロセス／スレッドが流行るんだろ
Erlangのような言語は言語のレベルでそういうものをサポートしている

目的がI/O多重化なら昔ながらのselect系のシステムコールが使える
WindowsならIOCP
Javaは1.4以降でnioという形でそれをサポートしてるし
Cならlighttpdで使われているlibeventのようなものがある

それはそうと、Windows XPあたりだと、デフォではTCPの同時接続数が10だかに
制限されているはずだが

289:デフォルトの名無しさん
08/12/09 12:08:39
>>288
ソースは？

290:デフォルトの名無しさん
08/12/09 12:11:40
>>289
「どれ」についてのソースなのか分からんが、
最後のものについてなら、そのまんま
Windows XP 同時接続数
でぐぐればいくらでも情報が手に入るだろ

291:デフォルトの名無しさん
08/12/09 12:18:08
UDPは制限あるの？

292:デフォルトの名無しさん
08/12/09 12:19:40
知らん
UDPにはconnectionという概念がないから、多分無いんじゃないかとは思うが
自分で調べたらどうだ

293:デフォルトの名無しさん
08/12/09 12:25:13
いやです
ありがとうございました

294:デフォルトの名無しさん
08/12/09 12:40:30
ググってみたが、XPのSP2から1秒間につき10コネクションという
制限がついたらしい。
時間をあければ万単位までいけるみたいだが。

295:デフォルトの名無しさん
08/12/09 12:40:39
Windows XP Professional の場合、ネットワーク経由で同時に接続することができるコンピュータの最大数は 10 です。
とありますが、
メッセンジャーに繋げてますが
この状態だと最大数は9になるのでしょうか？

296:デフォルトの名無しさん
08/12/09 13:11:01
制限解除するパッチもあるよ。公式じゃないけど。

297:デフォルトの名無しさん
08/12/09 13:11:23
もう少し詳しく調べてみた。

同時最大接続数が10に制限されるのは、listenする側の制限。
ようするに自分がサーバになる場合。

外向きの接続に関する制限は、half-open connectionが
1秒間に10個までに制限されている。(SP2から)
half-open connectionは相手がacceptしてない接続のこと。

外向きの接続数に関しては、能力的な限界以外に制限は無さそう。
ただし1スレッドにつき64ソケットの上限有り。(回避は可能)

298:デフォルトの名無しさん
08/12/09 13:13:51
>>297
え？内向きの制限はもともとサーバー系でない奴にはついていて、
XP SP2以降のは、外向きの制限だろ？

299:298
08/12/09 13:15:20
要は、listenじゃなくて、外に貼りに行くコネクション数に制限がついたってことな

300:デフォルトの名無しさん
08/12/09 14:35:58
>>298-299
そういう制限は見当たらなかった。
日本語の非プログラマ系のブログでそう書いてるところはあるが、勘違いだろう。

実際にセッションモニタ見てると、10なんて余裕で超えてるし。

301:デフォルトの名無しさん
08/12/09 14:47:37
>>300
は？
Event ID 4226でぐぐれよ
秒間の「外向きの」同時接続試行回数に関する制限で、
非公式のtcpip.sysに対するパッチも出ているから

302:デフォルトの名無しさん
08/12/09 15:00:15
P2Pとかやると直ぐでるからわかる

303:デフォルトの名無しさん
08/12/09 15:12:52
ああ、論点のずれが分かった
10個以上のTCP/IPのコネクションが維持できないって制限じゃないだろ
秒間に10個以上SYNパケット（TCPの最初のハンドシェイクで使う）を
投げないようにしているだけのはずだ

要するにスレッド沢山つくって並列でダウンロードさせようとしたところで
10個目以降ではconnect()呼んだ時点で制限にひっかかり、少なくとも他の
ハンドシェイクが完了するまでは待たされるってこった

304:デフォルトの名無しさん
08/12/09 15:36:05
ちゃんと297でhalf-open connectionと書いたんだが。
それを否定されたら、同時セッション数としか読み取れないよ。

305:デフォルトの名無しさん
08/12/09 15:45:44
そうだな、よく読んでなかった
すまん

306:デフォルトの名無しさん
08/12/09 17:47:13
クライアントでどこまでスケールさせる気だ。

307:デフォルトの名無しさん
08/12/09 20:04:18
googleのクローラでね？ｗ

308:デフォルトの名無しさん
08/12/10 17:25:35
シングルスレッドでダウンロードするとうまくいくのですが
マルチスレッドでダウンロードするとエラーが返ってきて
GetLastError() で戻り値を調べても 0 で何が原因か分からないのですが
どなたか分かりませんか？
WinXP です

309:308
08/12/10 17:29:32
マルチスレッドといっても、デバックの為、スレッドはひとつなので
競合などはおきないように設計しているのですけど、うまくいかないのです

310:デフォルトの名無しさん
08/12/10 17:39:11
さすがにそれだけで答えろって言われても、俺には無理だな。
GetLastErrorを呼ぶスレッドは合ってるの？

311:デフォルトの名無しさん
08/12/10 17:42:36
ダウンロードはどのAPIを使っているの？

312:デフォルトの名無しさん
08/12/10 19:15:01
>>311
ググってもでないのよねﾌﾌﾌﾌﾌﾌﾌﾌﾌ

313:308
08/12/10 19:19:36
>>311
機密事項なので答えられません＞＜

314:デフォルトの名無しさん
08/12/10 20:40:26
>>311
WinInet
InternetOpen
以外のAPIだけとは言っておく

315:デフォルトの名無しさん
08/12/10 20:42:31
>>311
とあるライブラリなんです
何かはいえませんが

316:デフォルトの名無しさん
08/12/10 20:55:51
俺は原因わかったよ
ここには書けないけど

317:デフォルトの名無しさん
08/12/10 21:36:55
内々に連絡しておいた。

318:デフォルトの名無しさん
08/12/11 03:36:59
Debug版を納品とかﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

319:デフォルトの名無しさん
08/12/11 09:31:46
ソースも示さずデバッグ依頼とな。

320:デフォルトの名無しさん
08/12/11 09:37:51
ソース。
ｽﾚﾘﾝｸ(mnewsplus板)

残念ながらもう消えてしまったようだが。

321:デフォルトの名無しさん
08/12/11 12:06:37
>>318
お主もなかなかのﾌﾌﾌﾌﾌﾌ

でもユーザー名ばれるのよねﾌﾌﾌﾌﾌﾌﾌｯﾌﾌﾌﾌﾌﾌｯﾌ

322:デフォルトの名無しさん
08/12/11 12:29:11
夜中にひとりでデバッグしてる時に
ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
とか
feeefeee feeefeee feeefeee feeefeee
とか見ると鳥肌が立ちそうになる・・・

323:デフォルトの名無しさん
08/12/11 14:11:44
POSIXスレッドでmutexロックでのデッドロックの回避法教えてください

324:デフォルトの名無しさん
08/12/11 14:27:28
馬鹿どもにマルチスレッドを走らせるな

325:デフォルトの名無しさん
08/12/11 14:36:53
>>323
2個以上のmutexを同時にロックしないというルールを徹底させるのが一番簡単かと

326:デフォルトの名無しさん
08/12/11 15:32:14
走る～♪
走る～♪
スレッドーたーちー♪

327:デフォルトの名無しさん
08/12/11 15:32:57
馬鹿ですいません＞＜

328:デフォルトの名無しさん
08/12/11 15:58:59
_beginthread( multi, 0, data );

>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～

329:デフォルトの名無しさん
08/12/11 18:46:03
APIの問題ではなかったようだ
設計の問題だったようだ
これは普通気づかない

330:デフォルトの名無しさん
08/12/11 20:45:05
Critical!
Criticalなのぉ～
Criticalな処理をしていなかったのぉ～
んぼおおおおおおおおおおおおおおおお

331:デフォルトの名無しさん
08/12/12 04:49:09
馬鹿はマルチスレッドやっちゃだめだよ。
死んだじっちゃんの口癖だった。
馬鹿って言うのは思考力が著しく劣る人なんだけど、
具体的に例をあげれば、自分で調べて答えを見つけられない人の事なんだ。

332:デフォルトの名無しさん
08/12/12 07:20:42
だ～か～らぁ～
ぐぐってもgooで聞いてもダメなのぉぉぉぉ～～～～

333:デフォルトの名無しさん
08/12/12 11:05:47
デッドロック予防とか、デッドロック回避とかで検索して、端から見ていってみ。

334:デフォルトの名無しさん
08/12/13 13:36:29
１スレッド
２スレッド
３スレッド
４スレッド
５スレッド
全部ためしたののですが１スレッドが一番早かったです
どうしてでしょうか？

335:デフォルトの名無しさん
08/12/13 14:23:51
よくあることです。

336:デフォルトの名無しさん
08/12/13 14:40:12
何を試したんだよ

337:デフォルトの名無しさん
08/12/13 17:25:44
キアイ

338:デフォルトの名無しさん
08/12/13 19:48:33
あるスレッドで処理した結果をメインスレッドに渡したいのだがどうすればいい？
_beginthreadexの第3引数に結果用のポインタを渡せばいいのか

339:デフォルトの名無しさん
08/12/13 20:43:24
典型的にはソウデスナ
処理してほしい内容と
処理結果の格納場所を
与えるのがよろしいかと思いますダ

340:デフォルトの名無しさん
08/12/14 01:39:30
>>338
CPUにお祈りする

341:デフォルトの名無しさん
08/12/14 02:58:11
>>334
マルチスレッド化して速くなるかどうかは状況による。
その状況がわからなきゃ、何とも言えない。

342:デフォルトの名無しさん
08/12/16 07:49:17
>>338
グローバル変数でいいよ
メモリ空間を共有してるのがスレッドのメリットなんだし

343:デフォルトの名無しさん
08/12/16 09:18:38
…

344:デフォルトの名無しさん
08/12/16 11:09:40
volatile最強

345:デフォルトの名無しさん
08/12/16 11:13:32
>>388
俺はそういう場合スレッドセーフなスマートポインタ使うな

スレッドにデータを渡す前に参照カウント増やしといて
スレッド側では使い終わったら解放

メインスレッドは結果が必要なくなればスレッドが終了していなくてもデータを解放できる

346:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/12/16 15:41:15
>>388は素人童貞

348:デフォルトの名無しさん
08/12/16 15:56:58
>>388 に期待

349:デフォルトの名無しさん
08/12/17 01:34:39
・メインスレッドが必ずサブスレッドより長生きするようにする。
　メインがサブをjoinなり必要に応じて中断するなりする。
・結果格納場所のポインタやコールバック関数のアドレスをサブに渡す。
　メインがUIスレッドの場合、サブからPostThreadMessageした方が楽かも知れない
・通信用メモリの解放責任をメイン側と決めておく

>>345みたいなサブスレッドだけ生き続ける設計は個人的に(GCの無い言語では)嫌だ

これらが難しいと思うなら>>342だね。カッコ悪いけど確実かな

350:デフォルトの名無しさん
08/12/17 01:53:27
PostThreadMessageは取りこぼしが発生するので使っちゃいけません。
PostMessageを代わりに使おう。

351:デフォルトの名無しさん
08/12/20 00:19:42
ところで、ファイバーってどうなん。
アイドル状態のスレッドでパカパカやって動かすとか
スケジュール処理なワーカスレッド代わりとかしか思い浮かばん。

漏れは、スレッドの処理は概ね、待ち処理とか先行処理なので、
あまり使い方が思い浮かばない。

352:デフォルトの名無しさん
08/12/20 01:51:56
>>351
ファイバーは移植のためにあるようなもので
新規プロジェクトで使う価値は無に等しい。

353:デフォルトの名無しさん
08/12/20 02:10:30
>>352
短絡杉
プリエンプティブであることは必ずしも望ましいことじゃない。
ゲームではファイバーが好まれる。
Larrabeeでもシェーダはファイバーで実装されるそうだ。
マルチコアでハイパフォーマンスだすためにファイーバーは重要。

354:デフォルトの名無しさん
08/12/20 02:31:59
自分でコンテキストスイッチとかめんどくせぇぇぇ

355:デフォルトの名無しさん
08/12/20 03:01:53
ちまちま排他処理すんのめんどくせぇぇぇ

356:デフォルトの名無しさん
08/12/20 12:21:50
>>352、353
マルチスレッドで複数の関数叩くのと、ファイバーを複数キックするのの違いってやっぱ、
同期処理が不必要(他のスレッドでキック中のファイバーは自動的に同期される？)だとか
スタックの制限(ファイバーキックされた段階でスタック指定できる)ですか？
いえ、無論色んな意味合いで違うことは判るけど。

357:デフォルトの名無しさん
08/12/20 16:20:24
int result = write( buf, size );
if( result == -1 && errno == EAGAIN ) SwitchNextCoroutine();
I/Oイベントドリブンなスケジューラをみたことある。↑みたいなの。
あとは同期が要らないってのが素晴らしい。

358:デフォルトの名無しさん
08/12/20 20:34:51
VisualStudio 2010にはC#のyieldを使ったファイバーもどきライブラリが付いてくるらしいね

URLﾘﾝｸ(channel9.msdn.com)

359:デフォルトの名無しさん
08/12/20 23:50:27
それは歪でいまいちだね～
まずコルーチンがあって
それにスケジューラを足してファイバー
イテレータ風に味付けしてジェネレータ(C#のyieldのことね)
という階層があるべき姿だと思うな。

360:デフォルトの名無しさん
09/01/10 00:18:47
64CPU環境でスレッドを256本生成したときに
struct data[2000];
なんてあって、dataの個々の要素を排他的にアクセスしたい場合
pthread_mutex以外に使えそうな手段ってありますか？

CASってどうやって使うのかよくわからんし助けて

361:デフォルトの名無しさん
09/01/10 00:48:43
pthread_mutexでマズい理由は？

362:デフォルトの名無しさん
09/01/10 00:58:20
>>361
2000個もpthread_mutex_tって用意して使えるのですかね？

363:デフォルトの名無しさん
09/01/10 01:08:25
発想が変？

364:デフォルトの名無しさん
09/01/10 01:47:06
mutexを2000個作って問題ないと思うよ。
自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
でパフォーマンスの問題が出たらそのときに対処を考える。
reader-writerロックが使えれば使う。

365:デフォルトの名無しさん
09/01/10 01:47:49
訂正。
> 自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
struct data[2000] ね。

366:デフォルトの名無しさん
09/01/10 18:28:23
>>362
pthread_mutex_t はただのデータだから、何個作っても
そのプロセスのメモリ以外の資源は使わない

367:デフォルトの名無しさん
09/01/11 00:54:05
連結リストをCAS使って実装するときのお手本ってありますか？

368:デフォルトの名無しさん
09/01/11 01:04:19
>>367
URLﾘﾝｸ(www.cs.rochester.edu)

369:デフォルトの名無しさん
09/01/11 01:14:01
双方向は無いのか........................

370:デフォルトの名無しさん
09/01/11 01:50:26
双方向でできると思ってんのかっ

371:デフォルトの名無しさん
09/01/19 00:40:02
rw_lockAPIが存在する環境で
同じrw_lock変数を以下のような構造で使うのって
問題ないでしょうか。

func()
{
rw_lock(read)
if　条件{
　　　rw_lock(write)
rw_unlock(write)
}
rw_unlock(read)
}

372:デフォルトの名無しさん
09/01/19 02:34:03
オレオレOSのオレオレrw_lock APIなら大丈夫だけど？

373:デフォルトの名無しさん
09/01/19 13:24:35
実装次第だが、普通に考えるとデッドロックするな

374:デフォルトの名無しさん
09/01/19 21:32:54
r_lock 確保してるんだから if の中の w_lock が取れないだろjk

375:デフォルトの名無しさん
09/01/20 06:28:27
なぜrでロックしないといけないのかわからんけど、条件に関わるのか？

376:デフォルトの名無しさん
09/01/20 11:21:30
>>375
このパターン自体は典型的なケースだろ
APIによっては、ReaderとWriterの他に「Writerに変更可能なReader」が用意されていることもある

377:デフォルトの名無しさん
09/01/27 16:00:09
WindowsでCreateThread中Cランタイムに含まれる関数を使うとリークを起こすとありますが、
普段からCreateThreadは使わずbeginthreadを使ったほうがいいんですか？
完全にCランタイム使わずってのも面倒だし、内部で使ってる関数があるかもしれない
そういうことまで考えてあえてCreateThreadを使うメリットはあるのでしょうか？

378:デフォルトの名無しさん
09/01/27 16:06:34
軽い

379:デフォルトの名無しさん
09/01/27 16:14:38
ない

380:デフォルトの名無しさん
09/01/27 17:56:15
_beginthreadexでおｋ

381:デフォルトの名無しさん
09/01/28 14:15:26
ないな

382:デフォルトの名無しさん
09/02/01 13:59:30
pthreadでmutexで
再起ロックする場合と
依存関係をハッキリさせてスレッドIDとFAST_MUTEXで判別

どっちが高速ですか？

383:デフォルトの名無しさん
09/02/01 15:33:29
後者。
以前計測したことがある。

ただし、依存関係の洗い出し作業がとても大変だった。
デッドロックに直結するから、とても気をつけないといけない。

要求性能がシビアだったから後者で仕事のためにやったけど、趣味ならば前者をお薦めする。
排他制御がボトルネックになるようなら、前者で実装すればいい。

俺の場合は、本当に特殊で制限が厳しかったから前者でやっただけ。

384:デフォルトの名無しさん
09/02/01 15:35:13
×排他制御がボトルネックになるようなら、前者で実装すればいい。
○排他制御がボトルネックになってから、後者で実装すればいい。

385:デフォルトの名無しさん
09/02/01 15:38:02
FAST_MUTEXって何？

386:383
09/02/01 16:18:24
色々ぐだぐだだな。
お家で寝たいよ。

387:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/01 23:54:31
加算をアトミックにしたいなら正しいんじゃない。

389:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/09 15:33:18
よりによってここに書くか。すれ違いだWin32スレ行け。
DLLの勉強一からやりなおせ。

最初から全コードのせときゃもっと早く回答ついたんだろうが、ウザイからオシエネ。

392:デフォルトの名無しさん
09/02/09 16:58:44
DLL内でnewしたのをEXE内で解放したらエラー出るんじゃない？
そもそもshared_ptrだって内部で参照カウント用にnewしてるからDLLじゃ使えない気がするなー。

393:392
09/02/09 17:02:58
スレッドは全然関係ないね。うん。

394:デフォルトの名無しさん
09/02/10 05:13:43
>>390
たぶんこれだけで死ねる。
　std::tr1::shared_ptr<A> a(new A);
　X(a)();

395:デフォルトの名無しさん
09/02/10 21:54:55
DLLか・・・COMについて調べたほうがいいんじゃないですかね
いろいろヒントあるよ

396:デフォルトの名無しさん
09/02/14 15:33:17
shared_ptr使ってるくせにdeleter知らないとか

397:デフォルトの名無しさん
09/02/19 23:31:28
>>288
Windows Xp home SP3 で自作のTCPサーバ運用してるけど、インバウンド接続の
同時接続数の制限が10ってことはないよ。
今モニタ見ても20人くらい繋がってる。
p2pがすごい数でつながってるだろうし

この件についてはいろいろなひとがよく確かめずにいろいろ書いてる。
自分でちょっとやってみればすぐわかる。

398:デフォルトの名無しさん
09/02/19 23:33:34
>>397
実装はともかくライセンスで制限されてるはず

399:デフォルトの名無しさん
09/02/19 23:37:37
そうなんだよね。　使わないでくれという約束で　みんな破って使ってるわけだ。

400:デフォルトの名無しさん
09/02/19 23:46:20
SQLだったかで試してたときにイベントログに制限されたメッセージが
出たことある。あとShare動かしてる時とか頻繁に出る気がする。
単純にセッションの制限では無かった筈。

401:デフォルトの名無しさん
09/02/20 00:12:50
MS製のサーバは独自に制限した実装　　IISじゃなくてPWSだっけ
WMEとかはレジストリいじって50人くらいつないだりしてたな。

402:デフォルトの名無しさん
09/02/20 02:13:42
それとは別に、セキュリティ的な話で、
SYN_SENTなソケットをシステム全体で
10くらいしか持てないって制限もあったはず。

403:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/02/22 19:36:03
>>403
ここらへんに何か書いてあるんじゃねーの？
URLﾘﾝｸ(msdn.microsoft.com)

405:デフォルトの名無しさん
09/02/23 04:04:56
>>403
バッファリング

406:デフォルトの名無しさん
09/02/23 21:19:24
スレッドに別のスレッドから信号を送って途中で処理をキャンセルしたいのですが、
現状、以下のようにしています。

void run() { // スレッド実行部
　for () { // 長いループ
　　...処理...
　　if (check()) return; // 処理をキャンセル
　}
}

check()でキャンセルのフラグをチェックし、このフラグを別のスレッドから書き換えるという方法です。
でもこの方法だとループ内の処理が重くなったときにキャンセル操作に対する反応も遅くなってしまうため
どうしたものかと悩んでます。
スレッド内でタイマーのようなものを発行して、定期的にcancel()のチェックをするといった方法はできないでしょうか？
環境はVC9です。

407:デフォルトの名無しさん
09/02/23 22:47:56
>>406
別スレッドから強制停止するとリソースリークの元だよ。
　　if (check()) return; // 処理をキャンセル
を重い処理の途中に幾つか入れる方がまし。

408:406
09/02/23 23:51:22
>>407
> を重い処理の途中に幾つか入れる方がまし。

どうも。やっぱりこういう単純な方法しかないですか。
重い処理を別スレッドで行わせながら
キャンセル操作の反応がよい安全な方法ってのはないんでしょうか。
cancel()を挿入しまくるというのもなんだかスマートじゃないなぁ･･･。

409:デフォルトの名無しさん
09/02/24 00:50:35
非同期に飛ばされるぐらいならコードが汚くなる方が良い

と思うのは俺だけじゃないよな？

410:デフォルトの名無しさん
09/02/24 01:12:42
その重い処理ってのがなんなのか
スマートとか言うならその重い処理をスマートに分割すりゃいいじゃない

どうしてもチェックしまくりたくないっていうなら処理を持ってるクラスのインスタンスを急にnullにしてやって
例外捕らえて終了してしまえ、最悪だけど

411:デフォルトの名無しさん
09/02/24 01:40:59
別プロセスにして殺すってのは？

結局そういうのって要求されるキャンセル応答時間次第。
人間相手ならmsecオーダでおｋでしょ。
きっとループ1回につき1msecもかからないのでは？

412:デフォルトの名無しさん
09/02/24 01:51:03
ワーカースレッド2つ以上用意にして
対処すればよくね？

複数個のスレッドでビジー状態になるなら
その処理内容そのものを分割しタスク化した方がいい

413:デフォルトの名無しさん
09/02/24 02:50:07
違う質問スレで質問した後でこちらを見つけたので一応こちらでも・・・

CreateThread関数で第三引数をクラスのメンバ関数にしたい場合は
どういう記述をすればいいのか教えてください
よろしくお願いします

414:468
09/02/24 02:56:15
>>410
>その重い処理ってのがなんなのか

例えば大きなサイズの行列計算や、待ち行列を使った探索問題なんかを想定しています。
問題を分割することはある程度はできるんですが、それはそれで頑張るとして、
それ以外のアプローチははないかなと。

>>411
> 別プロセスにして殺すってのは？

すみません。よくわかりません。
別プロセスならば殺しても元のプロセスに影響がでないという意味でしょうか。
>>410の後半で言ってることに近い

>>412
> ワーカースレッド2つ以上用意にして対処すればよくね？

同じスレッドオブジェクトをAとBの２つ用意して、
Aが動いてるときにキャンセルしたときはキャンセルしたふりをして
（Aの計算は次のcancel()チェックまで続いてる）、
新規の呼び出しがあったときはBを動かすというイメージですか？これはいけるかも…。

415:468
09/02/24 02:58:01
一部修正

>>410の後半で言ってることに近い
　↓
>>410の後半で言ってることに近いですか？

416:デフォルトの名無しさん
09/02/24 07:10:44
>>413
コールバック関数にはstaticなメンバ関数(クラスメソッド)しか使えない。
コールバック関数を使うAPIは大抵ポインタ型の引数を渡せるから、
クラスを使いたいときはそこにthisポインタを渡して使う。

417:デフォルトの名無しさん
09/02/24 08:52:04
>>413
できない
普通の関数作ってその中で呼び出す

418:デフォルトの名無しさん
09/02/24 16:53:09
>>416‐417
ありがとうございます
とりあえず、>>417の方法でやってみます

419:デフォルトの名無しさん
09/02/24 20:52:23
>>414
別プロセスにすると、ターミネートしたときのリソースの開放をＯＳがやってくれる
ってことではあるまいか。
それはともかく、その長い処理がうまく分割できず、どうしても時間がかかる場合は
汎的には、キャンセルボタンの入力を取得する側（フラグを立てる側ね）で、キャンセルが
押されたからしばらく待てっていうサインをユーザーに与える方が重要な希ガス。

420:デフォルトの名無しさん
09/02/24 21:45:33
別プロセスのほうがクリーンアップの点では簡単＆安心だなあ

ただ、多くの情報を受け渡したり、途中で通信が必要だったりすると
しんどいけどな

421:デフォルトの名無しさん
09/02/24 23:05:03
しんどいと言うか、性能の問題がでるかも

422:406
09/02/25 00:45:53
>>419-
なるほど。別プロセスにすることも検討できそうです。
なんとなく雰囲気は分かりました。どうもありがとう。

423:デフォルトの名無しさん
09/02/25 18:38:04
処理毎に別プロセスって、昔の業務アプリみたいだな。っていうか、
今でもVBあたりでそんな開発やってそう。

1画面＝1exeファイルで、画面間はsystem()でプロセス呼び出し。
画面フォーム上で入力したデータ等は、ファイルに書き出して渡す。

大抵、exeファイルの名前は全部数字と意味不明なアルファベットで、
メモリ食いまくりで、やたらに遅い。(w

424:デフォルトの名無しさん
09/02/25 19:28:47
大規模なアプリはマルチプロセスの方が開発しやすいね
Windowsの場合は性能的にマルチタスクに向かないけど

425:デフォルトの名無しさん
09/02/25 21:04:19
>>423
unixだとマルチプロセスは多いけどな。

VB6のアプリだとそういう作りになるのは仕方ない。
モジュール分割の手段がCOMしかない。
２０画面もあるとロードモジュールが１０M超える。
IDEに読み込んだりコンパイルするのにも一苦労。
プロセス間でDBのセッションを引き継げたらマルチプロセスでも軽くなるはずなのだけど、
それも出来ないからDBの接続でどうしても画面遷移が重くなってしまう。

426:425
09/02/26 01:19:09
>>424
マルチスレッドは、スレッド間のメモリ保護機構がないので、他スレッド
による破壊のリスクと引き換えに、高速なデータ共有が可能と思うが？
Windowsがマルチタスクに向かないとか、何を根拠に？

>>425
昔はメインメモリが少なく高価だったという事情もあるし、「unixだと」
という括りはどうかな？

20画面なんて、そんなに大きな規模なプログラムじゃないよね？その程度
の規模で単純にVBのソースだけなら、10MBを超えるようなことはないの
では？

確かにVB6当時のハード環境（Pentium 300MHz～1GHz,　メモリ64MB程度?）
でのビルドは遅かったかもしれないが、VBはVCよりは速かった様に記憶
しているけど？

それと、プロセス間でDBのセッションを引き継げないのは、VBや、Windows
に限定された話ではないのでは？

極端に処理が遅い業務アプリは、データベースの設計自体に問題があり、
無駄にDB間でレコードをコピーしたり、テーブルのリンクが必要だったり
ということが多い気がする。

427:デフォルトの名無しさん
09/02/26 01:55:03
プロセス間のデータ共有なら共有メモリがあるよ
特に親子関係があれば、mmap ANON とかでお手軽極楽

スレッドのメリットは（スレッド間なら）高速にディスパッチ出来る点だね
heap だろうとなんだろうとメモリは全部共有されるというのは
メリットでもあるけど、デメリットでもあるかな。
バグの原因になりがちだよね

428:デフォルトの名無しさん
09/02/26 03:45:35
構造化されたデータを別プロセスと共有メモリ経由でやりとりするとして

c構造体ならまあなんとかなるんだが（いやそれでも大変だが）
c++クラスだとすんごいやりにくい

何かウマい方法あります？

受け渡し用にクラス作るのもアホらしいし・・・
変態的テンプレートでなんとかなるもんだろうか

それとも単なる通信バッファとしてしか使わない？

429:デフォルトの名無しさん
09/02/26 03:52:42
C++ならCの構造体も使えるんじゃ…。

430:デフォルトの名無しさん
09/02/26 04:07:16
そういうのはソケット使って単純化してる。
プロセス間共有メモリは後で環境や仕様が変わったときに
変更が大変だし流用も難しい。バグも入りやすい。
パフォーマンスを上げたいとか、よっぽどの理由でも
ない限り使われないんじゃないかな。
スレッドと違って>>428の言うデメリットもあるし。
ウマい方法はありません。

431:デフォルトの名無しさん
09/02/26 04:53:41
>>426
酷いミスリードだな。>424はマルチプロセスによるマルチタスクという技法がWindows向けでないと言っているように見えるが。

432:デフォルトの名無しさん
09/02/26 04:59:25
IE8はマルチプロセスですぜ

433:デフォルトの名無しさん
09/02/26 05:49:22
>>426
お前は誰なんだ

434:デフォルトの名無しさん
09/02/26 06:45:39
unixといえば今でもパイプをfork/execで分け合ってというイメージが強いな。
DBのコネクションは知らないがファイルハンドルならプロセス間で受け渡せる。
Windowsにもハンドルを複製して子プロセスに渡すオプションはあるのだが、
OS/2やNTは最初からスレッドをサポートしてたのであまり使われない。

435:426
09/02/26 17:42:01
>>425
ハンドルの複製に失敗しますた。orz　426=423です。

>>431
未だにWindowsがunixに劣っていると思っている原理主義者か、TRON房かも。
何を以ってunixを定義しているのか聞いてみたい。

>>434
ハンドルをコピーしたりは、MS-DOSにもあったかな。INT 28Hだか忘れたけど、
プリンタスプーラ用の割込使えば、一応擬似マルチタスクで一部のシステム
コールを呼べた。

デュアルコアやクァッドコアのCPUだと、マルチスレッド化すると理論上
2倍や4倍で動くと勘違いしているヤツもたまにいるよね。おまえのOSは
いったいいくつプロセスが動いていると思っているんだと、小一時間。(略

436:デフォルトの名無しさん
09/02/26 18:11:07
WindowsがUNIXより優れてると思い込んでるなら
まずはその幻想をぶち壊す！

437:デフォルトの名無しさん
09/02/26 18:40:58
>>436
上条さん乙。
つか、んな事誰も言ってないから。

438:デフォルトの名無しさん
09/02/26 23:22:19
マルチスレッドスレでマルチプロセス云々言ってる時に何の前提もなく
「マルチタスク」なんて言う奴は普通にスルーでいいと思うんだけど...

439:デフォルトの名無しさん
09/02/26 23:47:59
よ～し、おじさんもマルチプログラミングとかタイムシェアリングとかの古語を持ち出しちゃうぞ。

440:デフォルトの名無しさん
09/02/26 23:51:02
>>435
実質、4coreXeonのシステムだとOpenMPで4スレッドにして3.9倍速くなるけどね。
逆に、>435のCPUはOSをアイドル状態で動かすだけでどんだけ負荷喰ってるんだって話だな。

次ページ