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

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

438:デフォルトの名無しさん
08/01/25 06:20:13
>>436
そんなの、スレッド本の第一章に書いてあるだろ。

439:デフォルトの名無しさん
08/01/26 13:54:13
Windowsで
4つのスレッドを開始させ、
一つのスレッドが終了次第、
ほかのスレッドも全て終了させる方法ってありますか？

440:デフォルトの名無しさん
08/01/26 14:02:01
>>439
そのように作ればそうなります。

441:デフォルトの名無しさん
08/01/26 14:07:17
>>440
すみません。
私の聞き方が曖昧でした。
手段を教えて下さい。

442:デフォルトの名無しさん
08/01/26 14:31:08
終了すると終了させるは微妙だが大きな違い

443:デフォルトの名無しさん
08/01/26 14:37:11
>>439
4人の子供のうち、誰か一人でも死んだという通知が来たなら、他の三人に死亡要求を掛ければよろしいかと。
子供が死亡要求を聞き届けてくれない仕様ならば、殺すしかありませんが。
いずれにしても、APIレベルで実装したいならAPIスレ、.Netでやりたいなら.Netスレ、そうでないならVSスレなり
初心者スレなり適当にどうぞ。

444:デフォルトの名無しさん
08/01/26 14:41:02
WaitForMultipleObjectsで４つのスレッドを待てば、どれか一つのスレッドが
終了したかが判るから、あとは終了イベントたてるなり(スレッドが参照していることが条件だけど)、
TerminateThreadするなり(非推奨)、好きなようにやれば。

445:デフォルトの名無しさん
08/01/26 14:54:02
マルチスレッド使って、CPU負荷分担みたいなことってできる？
２つのまったく動作が同じスレッド作って、２つのCPUリソースに処理を振り分けるとか？

446:デフォルトの名無しさん
08/01/26 15:25:58
できるできないで言えば普通できるに決まっとろう。

447:デフォルトの名無しさん
08/01/26 16:19:18
なにか共通で使うリソースがあって、同時にそれを使えない場合は、
如何に競合を回避するか考えないと、相手のリソース解放を待つのとかで、
同時に動作できる時間が減っちゃう。
CPU1: *-*-*　　　　***---
CPU2: -*-*- とか　---***
こんなのになったら意味無いし。

448:デフォルトの名無しさん
08/01/26 18:09:47
無駄だけどセマフォしかないわ、全部持つか、一個なら諦めろｗ

449:デフォルトの名無しさん
08/01/26 21:55:22
Windowsでは、有限バッファ問題（生産者消費者問題）はどう解決するのが良いでしょうか?
URLﾘﾝｸ(www.cs.is.noda.tus.ac.jp)

生産者も消費者も単一プロセス内のスレッドで、生産者・消費者はそれぞれ複数いるという
状況です。バッファがfullまたはemptyのときは、pushまたはpopの処理がブロックしてかま
いませんが、バッファ長は1や2ではなくもう少し大きくしたいと思っています。

UNIXだと、条件変数かセマフォを使えば簡単に実装できると思いますが、前者はWindowsには
無く、後者は単一プロセス内の同期として用いるのは効率が悪そうです。

Windowsは、VistaではなくXPを使っています。よろしくおねがいします。

450:デフォルトの名無しさん
08/01/26 23:22:41
何でもマルチスレッドにしたがるバカw

451:デフォルトの名無しさん
08/01/26 23:32:11
>>449
XPには条件変数は無いから。自分で作る。

452:デフォルトの名無しさん
08/01/27 00:24:29
条件変数って何があれば自作できるんだっけ?

453:デフォルトの名無しさん
08/01/27 00:30:14
Mutex/CriticalSectionとEventと変数でいいんじゃねーの？

454:デフォルトの名無しさん
08/01/27 00:40:01
>>453
おそらくその組み合わせでは条件変数もどきは作れないと思うのだが・・。
でも、もし大丈夫だとされている実装とか、MS推奨の実装を知っていたら教えて。

455:デフォルトの名無しさん
08/01/27 01:00:10
できないと思う理由を書いてくれ。

なんか、条件変数に過大な期待をしてるみたいだから。

456:デフォルトの名無しさん
08/01/27 01:10:01
broadcast考えなきゃ、Auto Reset Eventを
SignalObjectAndWaitで待てば済む話じゃね？

457:デフォルトの名無しさん
08/01/27 01:23:45
>>455
Mutexの開放とEvent待ちをアトミックに行うことができないから。

たとえばここ URLﾘﾝｸ(docs.sun.com)
の一番下にあるようなコードの、pthread_mutexをCriticalSectionに置き換えて、
pthread_condを自動リセットのEventに置き換えたとすると、

バッファが空の状態で、スレッドAがデータを取り出そうとする
Event待ちの寸前でコンテキストスイッチ
まだバッファが空の状態で、スレッドBがデータを取り出そうとする
Event待ちの寸前でコンテキストスイッチ
スレッドCがデータを投入
スレッドCがSetEvent
スレッドCが再度データを投入
スレッドCがSetEvent
スレッドAがイベント待ちに入り、すぐ戻る
スレッドAがデータ取り出し完了
スレッドBがイベント待ちに入る。データがあるのにイベント待ちから戻れない

となる恐れがない? (CSのEnter/Leaveは省きました)

URLﾘﾝｸ(www.linux.or.jp) の、
> 条件変数はいつでも mutex と結びつけられていなければならない。これは、あるスレッドが条件変数を
> 待とうとしている時に、他のスレッドが、先のスレッドが実際に条件変数に対して待機するその直前に
> 条件を送信する、という競合条件を避けるためである。
を参考にしました。

458:デフォルトの名無しさん
08/01/27 01:30:15
というわけで、producer-consumerのうまいコード例があればお願いします。

459:デフォルトの名無しさん
08/01/27 01:31:34
投入データの個数をセマフォで管理しとけばいいんじゃないかな
データ投入後→セマフォを1上げる
データ取り出し前→セマフォを1下げる（データがない＝セマフォが0の場合は投入される＝1以上になるまでブロック）

460:デフォルトの名無しさん
08/01/27 01:35:29
>Mutexの開放とEvent待ちをアトミックに行うことができないから。
はいはい。SignalObjectAndWait, SignalObjectAndWait。

461:デフォルトの名無しさん
08/01/27 01:39:35
>>460
んー、この用途に使えるのか。サンクス。調べてみます。

>>459
最悪それでいこうとおもってます。けど460のでいけるならそれがベター。

462:デフォルトの名無しさん
08/01/27 01:40:44
というか、Producer-Consumerなら、スレッドプールつかって
あとは知らぬの半兵衛を決め込めばいいような気がしてきたぞ。
Producer() {
{
CriticalSectionLock csl(cs);
return if list.full?
list.push( somethings )
QueueUserWorkItem( Consumer );
}
}
Consumer(){
{ CriticalSectionLock csl(cs);
workitem = pop();
QueueUserWorkItem(Producer);
}
SomeWork;
}

463:デフォルトの名無しさん
08/01/27 01:41:59
>>462
そういうのもあるんですか。そっちも調べてみます。
ありがと。

464:デフォルトの名無しさん
08/01/27 01:57:33
>>456
ブロードキャストしたい場合は

465:デフォルトの名無しさん
08/01/27 02:08:57
その場合は、根本から考え直しだよね。
APRみたいに、Manual Rese Eventを待つたびに、待ちスレッド変数をインクリメントして
起こされるとデクリメント。自分が最後に起こされたスレッドかどうかを判断して、
ResetEvent発行するとかさ。

466:デフォルトの名無しさん
08/01/27 02:11:42
manual resetにするわけか。めんどくさいね。

467:デフォルトの名無しさん
08/01/27 14:51:01
結論：Windowsはクソ

468:デフォルトの名無しさん
08/01/27 15:00:27
条件変数を作るとして、それに使うWindowsの同期オブジェクトはどれが軽くてお勧めか？

469:デフォルトの名無しさん
08/01/27 15:18:26
CriticalSectionにSignalObjectAndWaitできるの？

470:デフォルトの名無しさん
08/01/27 15:18:47
>>468
Vistaを使う

471:デフォルトの名無しさん
08/01/27 16:59:39
>>435
thread pool化した。8thread上げといてそれを、
pthread_cond_wait/signal/broadcast
pthreaf_mutex_lock/unlock
で、ぶん回した。
non thread時の倍ほどがのスピードが、漸くでた。

単純にctreate/joinだけだと、メチャメチャコストが高いのですね。
このときは、non thraed時の8倍ほど時間がかかった。

472:デフォルトの名無しさん
08/01/27 18:19:52
>>468-469
CSが使えないんだとしたらエラく遅くなるよな。
実際のところどうなのか教えてエロい人。

473:472
08/01/27 18:24:54
URLﾘﾝｸ(www.cs.wustl.edu) の3章に実装例があった。
どれも大変な事になっているな。たぶん、pthread_cond_broadcast()を実現しようとしているからだと思うが。

474:デフォルトの名無しさん
08/01/27 20:08:28
VS2005、C++でWin32ウィンドウプログラムを作成しています。
キューの中身が空の間、スレッドを待機させたいのですが、while(que.empty())
{
Sleep(0);
}
とすると、CPUはぶんまわされるわ、スレッド終了フラグも受け取れないわで困っています。
キューにデータが入った瞬間にスレッドが回りはじめ、かつ終了フラグも受け取るためにはどうすればよいのでしょうか?
初歩的な質問ですみませんがよろしくお願いします。

475:デフォルトの名無しさん
08/01/27 20:29:07
釣り?

476:デフォルトの名無しさん
08/01/27 22:12:47
いえ、釣りではないのですが…
もう少し調べてみます。
それでも分からなければ初心者スレに行きます。
スレ汚し失礼しました

477:デフォルトの名無しさん
08/01/27 22:51:27
とりあえず、セマフォを使ってみよう。

478:デフォルトの名無しさん
08/01/27 22:54:49
というか、今までの話題がまさにそのProducer/Consumerパターンについてなわけだが

479:デフォルトの名無しさん
08/01/28 00:08:21
>>449-
.NETならこれ
URLﾘﾝｸ(msdn.microsoft.com)
Vistaならこの記事がおすすめ。
URLﾘﾝｸ(msdn.microsoft.com)

480:デフォルトの名無しさん
08/01/28 00:09:22
>>479
C++でXPなんです・・

481:デフォルトの名無しさん
08/01/28 01:08:54
つうか、セマフォ使えや、カス

482:デフォルトの名無しさん
08/01/28 01:20:54
メータードセクションだろ普通

483:デフォルトの名無しさん
08/01/28 01:21:26
>>481
誰にいってんの？

484:デフォルトの名無しさん
08/01/28 01:23:40
>>482
へぇ。そんなのあるんだ。プロセス間でも使えて、一定回数はカーネルに落ちないでspin？

485:デフォルトの名無しさん
08/01/28 02:31:00
全部ホシュするなら、全部ヤッパ明渡せヤゴラ、でＯＫ

486:デフォルトの名無しさん
08/01/28 07:52:58
?

487:デフォルトの名無しさん
08/01/28 09:51:29
VMwareでLinux上げてpthread使えば解決

488:デフォルトの名無しさん
08/01/28 10:42:06
queueに要素があるかは、>>477,>>481の通りセマフォでやればいいんじゃない?
増減するリソースを管理するんだからちょうどいいでしょ。
フラグの変更はイベントにでもして一緒に待つか、queueに終了って言うなにかを投げ込めば？

489:デフォルトの名無しさん
08/01/28 18:01:56
Linux野郎なんでWindowsには全く疎い俺参上！

Windowsの独自スレッドだけでpthreadはないの？

あと、pthreadとWindowsスレッドを比較した利点・欠点
がまとめてあるHPとないでしょうか？

490:デフォルトの名無しさん
08/01/28 20:46:19
>>484
スピンで待たせるなら、プロセス内専用だけどWindowにもInitializeCriticalSectionAndSpinCountなんてものもあるよ。

491:デフォルトの名無しさん
08/01/28 22:07:07
メータードセクションは、Windowsの話だけど･･･

492:デフォルトの名無しさん
08/01/29 06:27:19
CriticalSectionがspinなのはわかってるよ

493:デフォルトの名無しさん
08/01/29 06:34:26
>>489
Linuxにも疎そうだな

494:デフォルトの名無しさん
08/01/29 09:57:59
どうしてもpthreadがいいなら、pthreads for Win32があるでしょ。
以前mingwでつかってたよ。VCでも使えたはず。

495:デフォルトの名無しさん
08/01/29 12:58:59
下のようなクラスを作って、Monitorでのロックと比較してみた。
EnterWithContextSwitchで、ロックがほとんどかち合わないで誤差の範囲で軽く、ロックが頻繁な場合だと
明らかに遅くなる。Enterは確実に遅い。

class SpinLock {
volatile int _isEntered;
public void Enter() { while (Interlocked.CompareExchange(ref _isEntered, 1, 0) != 0) { }}
public void EnterWithContextSwitch() {while (Interlocked.CompareExchange(ref _isEntered, 1, 0) != 0) {Thread.Sleep(0);}}
public void Exit() {_isEntered = 0;}
}
//試したのはこんな感じ　各スレッドで
for (int i = 0; i < _loopCount; i++) {
thp.LockDeleg(thp);//ここでLockして
DoWork(_jobTime);//ここで指定時間処理して
thp.UnLockDeleg(thp);//ここでUnlock
}
対象のロックはmontor,SpinLockともども複数生成して、ロックするときにランダムでロック対象を決めるようにした。生成するロック数も多い場合、少ない場合色々試してみた。

環境はXP Sp2 C# .NET2.0 DualCoreのアスロン何たら。
テスト中はCPUを使い切る場合もあれば各CPUが70%ぐらいで推移する場合もあり。どちらのロックでそうなるかは不明。多分SpinLock。
参考URL
URLﾘﾝｸ(msdn.microsoft.com)

何か間違ってる？ついでにおまいらのマルチスレッドに関する考え方、使い方を教えてくれ。
教えてエロイ人

496:デフォルトの名無しさん
08/01/29 18:13:34
何がしたいのこれ？

497:デフォルトの名無しさん
08/01/29 18:26:19
.netのモニターオブジェクトと自前スピンロックの性能評価？

498:デフォルトの名無しさん
08/01/29 18:42:28
具体的に何を計りたいのかよくわからん。

ついでについては、ロックがかち合う可能性を下げるように設計する。

499:495
08/01/29 18:54:29
違う回線よりすいません。
説明不足で申し訳ないです。
言われるとおり、自作スピンロックでどれだけロックが軽くなるかの調査です。
いくつかの記事で、SpinLockでのcpu消費の方が、コンテキスとスイッチより軽いと言っていたので試してみました。
結果が記事と逆になってしまったので自分のコードが何かおかしかったのかと。

500:デフォルトの名無しさん
08/01/29 19:10:11
スピンロックはマルチプロセッサじゃないと効果無いんじゃないか？
スピンしてる間にロックが外れれば、カーネルに落ちなくて済むじゃん

501:デフォルトの名無しさん
08/01/29 19:27:06
＞環境はXP Sp2 C# .NET2.0 DualCoreのアスロン何たら。
って書いてあるから、２つあるんでそ。

502:デフォルトの名無しさん
08/01/29 19:31:05
あ、ほんとだ。失敬失敬。

503:デフォルトの名無しさん
08/01/29 19:33:43
単純なサンプルで重い、軽い、と早い、遅いを同列に語っても意味無いかと。

あとSleep(0)の分解能なんてろくに無いんだから
いちいちロックされてるたびに呼んでたら無駄に待たされる。
ただ、一般的には、他の誰かが処理してるからCPU時間を明け渡してあげることで
いち早くロックを取得できる可能性をあげる意味でSleepを使う

Sleep(0)の分解能調べて見て、中のジョブがどれぐらい時間かかってるか
調べて見れば、あなたのいう軽いとか遅いとかがより深く理解できると思う。

Win32だったらCriticalSectionで一発だったんだが
.netはLockかInterlockしか無いのかな

504:デフォルトの名無しさん
08/01/29 19:33:52
public void EnterWithContextSwitch() {while (Interlocked.CompareExchange(ref _isEntered, 1, 0) != 0) {Thread.Sleep(0);}}
というか、これ "Sleep(0)" が原因でねーの。他にするタスクがないとき、CPU休まないじゃん。

505:デフォルトの名無しさん
08/01/29 21:06:30
.NETのロックは元々クリティカルセクションだよ。

506:デフォルトの名無しさん
08/01/29 21:15:59
単純なスピンロックなんざそもそも間の処理が極めて短時間で
競合なんてまず滅多に起こらん場合にしか向かん。

507:デフォルトの名無しさん
08/01/29 21:27:30
どうもインタロック操作が極端に軽いと勘違いしてる奴や記事が多いな。
.NETなんて単純にロックでもそう大差はないのに。

508:デフォルトの名無しさん
08/01/29 21:39:37
ああこれは件のMSDNの記事の事じゃないので念のため。

509:495
08/01/29 21:59:01
>>506
そのようだ。
>>507
極端に軽いと勘違いしてた。

今は反省している

510:デフォルトの名無しさん
08/01/30 13:04:30
>>21によれば、.netの機能をそのまま使えば良いんじゃないか？

511:デフォルトの名無しさん
08/01/30 19:09:40
うんそう。
あえてスピンロックにするのはインタロック操作1回分までも節約したいとき。
2回→1回

512:デフォルトの名無しさん
08/02/03 11:08:05
環境visualstudio2005 vc++
_beginthreadexを使ってメインを合わせて合計3個と100ms毎の割り込みをさせてるんですが、
assert(0)が有効にならない場合があります。マルチスレッドで緊急にプログラムを停止させたい場合は
どうすればいいんでしょうか？

513:デフォルトの名無しさん
08/02/03 11:18:51
ExitProcess

514:デフォルトの名無しさん
08/02/03 11:33:51
>>512
WaitoForSingleObjectとSetEventを使う。

515:デフォルトの名無しさん
08/02/03 12:06:49
assert(0)

516:デフォルトの名無しさん
08/02/03 17:58:20
>>514
Waito ?

517:デフォルトの名無しさん
08/02/03 18:28:11
WaitoSinguruObujecuto と SinguruIvento

518:SettoIvento ならわかるが...
08/02/03 21:12:20
SinguruIvento ?

519:514
08/02/03 21:19:11
ゆるしてっ！！

520:デフォルトの名無しさん
08/02/04 19:47:15
>>512
俺を使え。全力でとめてやるぜ

521:デフォルトの名無しさん
08/02/08 14:49:26
生成したスレッドから、
ウィンドウハンドルを使用するマクロを使うためにはどうすればいいですかね？

522:デフォルトの名無しさん
08/02/08 14:54:37
わかりやすい日本語でお願いします。

523:デフォルトの名無しさん
08/02/08 18:17:55
>>521
ウインドウハンドルが欲しいのかな？

524:デフォルトの名無しさん
08/02/11 23:34:04
Visual Studio.NET 2003で、Win32API、C++のプログラムをしてるんですが、
複数スレッド同時に、クラスのオブジェクトをnewしまくると、

・HEAP[aaa.exe]: HEAP: Free Heap block 3c04d0 modified at 3c04e0 after it was freed
・0xC0000005: 場所 0xfeeefeee に書き込み中にアクセス違反が発生しました。。
・0xC0000005: 場所 0xfeeefeee を読み込み中にアクセス違反が発生しました。。

などのエラーがでます。
何か回避方法はないでしょうか？

newしてるのは同じクラスのオブジェクトですが、
static変数は持っておらず、グローバル変数も共用してません。
共用のものとしてはstatic関数を持ってますが、使ってはいません。

525:デフォルトの名無しさん
08/02/12 00:22:37
> 何か回避方法はないでしょうか？

バグを直す。

526:デフォルトの名無しさん
08/02/12 00:41:03
ランタイムがシングルスレッド用になってんじゃね？

527:524
08/02/12 00:58:26
>>525
シンプルな以下のクラスでテストしてみたんですが、
やっぱり同じエラーが出ます。

class TestClass{
public:
TestClass();
virtual ~TestClass();
};
TestClass::TestClass(){}
TestClass::~TestClass(){}

>>526
ランタイムってなんでしょうか？
VCで設定するものですか？それとも実行する環境に依存するもの？

528:デフォルトの名無しさん
08/02/12 01:01:02
クラスの定義よりも寧ろ、「newしまくる」方を晒せよ。

529:524
08/02/12 01:06:18
>>526
ありがとうございます！

VCの設定で、
プロジェクトのプロパティ→C/C++→ランタイムライブラリを、
マルチスレッドデバッグにしたらエラーが出なくなりました。

530:デフォルトの名無しさん
08/02/12 01:11:48
ﾔﾚﾔﾚ

531:デフォルトの名無しさん
08/02/12 12:34:51
>>529
シングルスレッド用でコンパイルが通ったてことはCreatThreadを使ってるのかな？_beginthreadExを使ったほうがいいよ。

532:524
08/02/13 02:11:46
>>531
_beginthreadExは知りませんでした。
調べてみます。ありがとう。

533:デフォルトの名無しさん
08/02/13 10:20:00
グローバル変数使う標準Cライブラリ(strtokとか)を使う場合、_beginthreadExじゃないとまずいことになる。
そうじゃないならCreateThreadでも特に問題なかったと思う。

534:デフォルトの名無しさん
08/02/13 23:11:17
>>533
mallocやnewとか、VCランタイムのいろんなものがやばい。
コンパイラベンダでも無い限り、CreateThread使う必要なし。

535:デフォルトの名無しさん
08/02/14 00:54:08
マルチプロセッサ環境でストアバッファのデータを反映させたい場合
pthreadだとmutex使えばいいんでしょうか？

536:デフォルトの名無しさん
08/02/14 01:38:26
>>535
同期プリミティブの使用でフラッシュしてくれなかったら、どうにもならない。

537:デフォルトの名無しさん
08/02/14 02:08:24
>>535
んー、volatileかな。

538:デフォルトの名無しさん
08/02/14 13:03:57
メモリバリア

539:535
08/02/14 23:26:30
恥のかきついでに。。。
フラッシュされるということはmutexのアンロック後に
他のスレッドから同期プリミティブを使用せずにメモリを参照しても
mutexがアンロックされた時点までの操作は完了してると見なしていい
この解釈は合ってるのかな

540:デフォルトの名無しさん
08/02/15 01:55:14
posixがそれを要求してる、って
URLﾘﾝｸ(d.hatena.ne.jp)
ここらへんに書いてあった。

541:535
08/02/15 02:19:14
なるほど。
URLﾘﾝｸ(www.opengroup.org)
ここにある関数を呼び出した時点でメモリが同期されるわけですね
ありがとうございました

542:デフォルトの名無しさん
08/02/15 11:02:56
>>539
mutexのアンロックで書き込み側プロセッサのキャッシュがメモリと同期されても、
それだけでは読み込み側プロセッサのキャッシュはメモリと同期されないのでは？
読み込み側にも同期プリミティブ（具体的にはmutexのロック）が必要なはず

543:535
08/02/16 15:34:51
>>540の"同時アクセスさえ防いでおけばすべてうまく行く"
というのを信用したんですが・・・どっちが正しい？

544:デフォルトの名無しさん
08/02/16 16:21:03
キャッシュと同期オブジェクトは別じゃないのか。

545:デフォルトの名無しさん
08/02/16 16:21:28
同時アクセスを防ぐ＝読み側もmutexなりでロックしにいく

でも読み込みだけならロックいらないよね。volatile最強！

546:デフォルトの名無しさん
08/02/16 16:39:51
>>545
一応マジレスしておくと、volatileでは確実に読めることが保証されない。安全を期するならロックした方が楽。
# 理由については割愛。

547:デフォルトの名無しさん
08/02/16 17:41:24
CPUのマニュアル読むのが一番

548:デフォルトの名無しさん
08/02/16 17:42:24
>>543
読み込み側もmutexをロックしないと、同時アクセスを防げないじゃないか。
まだ書き込み側がmutexをアンロックする前かもしれないのに。

549:デフォルトの名無しさん
08/02/17 15:13:07
pthreadの、pthread_join()とsleep()の関係について質問します。

主系スレッドZにて、子スレッドa, b, cをpthread_create()により作成します。子スレッドa, b, cは一定時間経過後に処理を行います。一定時間経過するのを待機する場合、sleep()を使っています。

主系スレッドZでは、子スレッドa, b, cが終了するのを待つために、pthread_join()を使っています。しかし、子スレッドa, b, cがsleep()で待機しているときを、子スレッドが終了した時と勘違いしているようです。

現在では、子スレッドa, b, cが終了する前に、それぞれが主系スレッドZにsignalを送るようにしています。主系スレッドZでは、signalが来るまで待機としています。

最初にやっていた、pthread_join(), sleep()の組合せの方がスマートだと思うのですが、こちらの方法でうまくやるのは無理なのでしょうか？

550:549【言語】【実行環境】【その他突起する事項】
08/02/17 15:18:17
環境を書き忘れていました。

【ＯＳ】debian/etch

【言語】C(pthread/posix)

【実行環境】
glibc2.3.6
gcc4.1.2
kernel 2.6.18-6-486
libpthread NPTL2.3.6

551:デフォルトの名無しさん
08/02/17 15:21:59
突起ﾌｲﾀ

552:デフォルトの名無しさん
08/02/17 15:50:00
>主系スレッドZでは、子スレッドa, b, cが終了するのを待つために、
>pthread_join()を使っています。しかし、子スレッドa, b, cがsleep()で待機しているときを、子スレッドが終了した時と勘違いしているようです。

コード晒してみてくれ

553:549
08/02/17 16:23:25
どうやら勘違いだったようです。

真の原因は、Zでログファイル用に
fp_glb=fopen("Z.log","w");
として、fpを持っているのですが、子スレッドが、
fprintf(fp_glb, "log write thread name [a]\n");
として、共通のログファイルに書き込みを行おうすると、死んでいるようでした。子スレッドでは、書き込む前に排他ロックを行っているのですが、主系スレッドでは行っていないことが原因だと思っています。

554:デフォルトの名無しさん
08/02/17 16:24:12
無茶苦茶だな。

555:デフォルトの名無しさん
08/02/19 09:12:29
VC++にpthreadはないのでしょうか？

556:デフォルトの名無しさん
08/02/19 11:47:28
>>555
>>494

557:デフォルトの名無しさん
08/02/20 19:33:15
自分から終了することもあるし、外部から終了通知を受け取ることもある
ようなスレッド関数について質問です。
こういう場合、（スレッド関数はすでに終了してるぞ！）フラグや
（外部から終了通知が出されたぞ！）的な何かはいったいどうやって実装していますか？
自分はいつも

bool isActive = false;
bool IsThreadActive() { lock {return isActive} }
void SetThreadActive(bool flag) { lock {isActive = flag; } }
void ThreadFunc() {
　SetThreadActive(true);
　try {
　　while (IsThreadActive()) {
　　　... いろんな処理
　　}
　} catch(...) {
　　SetThreadActive(false);
　　throw;
　}
}

的なやり方でやってしまっているのですが、
これって正しいのでしょうか？
また、もしあればもっといい方法を教えていただけると助かります。

558:557
08/02/20 19:36:19
書き忘れました
while (IsThreadActive()) {
　... いろんな処理
}
の内部から breakで抜けることもあります。
（SetThreadActive(false)も付け足してください）

559:デフォルトの名無しさん
08/02/20 19:41:56
終了要求フラグとすでに終了してるぞフラグは別にした方がいいんじゃないかな
すでに終了してるぞフラグが要るかどうか（何に使うのか）にもよるような

560:デフォルトの名無しさん
08/02/20 20:03:24
スレッドでいくつかの処理を行いたいのですが、
その処理の内容が
１、実はまったくスレッドが必要にならない場合がある
２、処理の行われる間隔が長いので、
　　続く処理が無いようならとりあえずスレッドを終了させたい
というもので、ある処理のリクエストが入ったとき、

＊スレッドが稼動していればそのままリクエストを追加
＊稼動していなければ新たにスレッドを起動して処理を開始
＊終了要求が入ったらすべてのリクエストを破棄＆スレッドを終了

ということがしたいのです。

561:デフォルトの名無しさん
08/02/20 20:13:33
スレッドを終了する要因がメイン側からの要求だけなら、
スレッドが生きてるかどうかはメイン側が完全に把握してるはずなので、
子スレッド側から「すでに終了してるぞ」フラグを操作する必要はないはず

562:デフォルトの名無しさん
08/02/20 20:23:14
>>561
スレッドを終了させる要因には、メイン側からの通知もそうですが、
子スレッド内での例外や、自殺も含まれます。
結局、これはフラグで操作するしかないのでしょうか？
というのも、「スレッドをフラグで操るなんて危なすぎ」みたいな話を聞いたことがあるので・・・
それにconditionとか、なんとなくかっちょいい機能を使いたいような気もします

563:デフォルトの名無しさん
08/02/20 20:30:57
>>561
すいません。分かりにくかったですね。これも追加してください
＊リクエストが無ければ、とりあえずスレッドを終了（再びリクエストが来たら再度起動）

564:デフォルトの名無しさん
08/02/20 20:55:19
例外で死ぬなら、残ったリクエストを誰かが引き継がなきゃいけないような・・・
キャッチできるなら再開して残りのリクエストを処理する方がいいんじゃないかな
リクエストキューとスレッド生存フラグは単一のロックで操作しないとまずいことになると思う
終了要求フラグは別のロックでも構わないけど、一緒にしとくのが無難かと

親側
lock {
リクエスト投入
if (スレッド生存==false) { 子スレッド起動; スレッド生存=true }
}
子側
loop {
lock {
if (終了要求) { スレッド生存=false; return }
リクエスト取り出し
if (もうリクエストないよ) { スレッド生存=false; return }
}
try { リクエスト処理 } catch { エラーメッセージを吐くとか }
}
たぶんこんな感じ？

565:デフォルトの名無しさん
08/02/20 20:57:14
終了してるかどうかはそのためのもの（WinならWaitForSingleObjectとか）で調べるでしょう。

566:デフォルトの名無しさん
08/02/20 21:08:10
>>565
スレッドが例外とかで突然死した場合はメイン側でWaitFor～なりで捕まえて再起動するしかないけど、
リクエスト投入時の新スレッド起動判断をそれでやると、
その直前にリクエストがキューにないと判断したため自発的に終了しつつあるスレッドと入れ違いになる可能性が・・

567:デフォルトの名無しさん
08/02/20 21:25:45
>>564
おお、なるほど。そういう風にやればいいんですね。
>>557だと、「いろいろな処理」中にisActiveがfalse、
かつリクエスト追加でフラグがtrueになるとスレッド二つになりますし、
タイミング的にスレッド消える危険もありますね。
それをテンプレにしていろいろ試してみたいと思います。
ありがとうございました。

568:デフォルトの名無しさん
08/02/20 22:14:25
俺ならこんな構造にする。
・リクエストを出すスレッドはイベントループを持つ。
・作業スレッドはリクエストキューと終了要求フラグを見ながら愚直に仕事をする。
・作業スレッドが処理を1つ済ませたり終了したりしたら、
1回だけ呼ばれるコールバックを要求元スレッドのイベントループに登録する。
・コールバックは要求元スレッドで走り、処理結果やエラーを通知する。
問題は、イベント待ちで寝ているときに目を覚まさせる方法が
既成のイベントループに必ずしも用意されていないこと。

569:デフォルトの名無しさん
08/02/21 09:40:13
毒を投げればいいだろ

570:デフォルトの名無しさん
08/02/21 09:48:43
基本的にスレッドはブロッキング操作があるようなものを非同期で行わせるために俺は使ってるから，
イベントループとか使えないんだよね

571:デフォルトの名無しさん
08/02/21 12:56:56
一方、漏れは匙を投げた。

572:デフォルトの名無しさん
08/02/21 19:03:51
double pi=3.14159265358979823846;
if((fp=fopen("PI.bin","wb"))==NULL)
printf("\aファイルをオープンできません。\n");
else{
fwrite(&pi,sizeof(double),1,fp);
fclose(fp);
}

Ｃ言語で↑のようにpiをバイナリファイルに書き込んで、
ＢＺというバイナリエディタで開いたのですが”$-DT・ @”(文字部)と表示されました。
その後にfread関数でPI.binの内容をプログラム上で出力すると3.1415926……とさきほどの数字に限りなく近い数字できちんと表示されたのですが
バイナリエディタで見ると変な文字に変わってしまうのは、何が原因なのでしょうか？これをバイナリファイルとして正しく見れる方法はあるのでしょうか。

573:デフォルトの名無しさん
08/02/21 19:04:04
ブルータス！お前もか！

574:デフォルトの名無しさん
08/02/21 19:07:45
>>572
スレタイと何か関係あった？

575:デフォルトの名無しさん
08/02/21 19:10:06
>>574
完全に誤爆です
すいませんでしｔ

576:デフォルトの名無しさん
08/02/26 01:43:14
>>572
原因はお前の頭が悪いこと。
そもそもスレ違い。

577:デフォルトの名無しさん
08/02/26 04:30:54
5日も前に誤爆だったと謝罪済みのレスに文句言う馬鹿って一体何考えてるの?

578:デフォルトの名無しさん
08/02/26 10:36:12
脊髄で書いてるのだろう

579:デフォルトの名無しさん
08/02/27 17:15:56
脊髄電脳化ｗ

580:デフォルトの名無しさん
08/02/28 00:56:57
マルチスレッド対応の
ハッシュリストのソースコードとかある？

581:デフォルトの名無しさん
08/02/28 12:32:38
ハッシュは速いのが売りなんだから、まるごとクリティカルセクションで包んでおけ

582:デフォルトの名無しさん
08/02/28 12:51:50
>>580
Javaのjava.util.concurrent.ConcurrentHashMap

583:デフォルトの名無しさん
08/02/28 13:19:30
javaならHighly Scalable JavaのNonBlockingHashMap等
URLﾘﾝｸ(sourceforge.net)

584:デフォルトの名無しさん
08/02/28 16:02:03
>>581
意味ねーｗ

585:デフォルトの名無しさん
08/02/29 23:39:30
同期処理なんてしなくてよし。
すべては運任せ。
マルチスレッドの邪神様に任せておきなさい。

586:デフォルトの名無しさん
08/03/03 11:34:48
コア1個ならなんとかなるさ、きっと

587:デフォルトの名無しさん
08/03/03 21:36:55
●５コアは一個だが、ＨＴだった

588:デフォルトの名無しさん
08/03/03 23:09:15
HTといえば、マルチコアの場合は異なるコア同士が同じキャッシュラインに
アクセスしない方がいいけど、HTの場合は逆になるの？

589:デフォルトの名無しさん
08/03/03 23:49:44
マルチプロセッサ・マルチコア・HTで論理CPUが８個とかってどこのXEONだっけ？

590:デフォルトの名無しさん
08/03/04 16:41:04
AMDのです

591:デフォルトの名無しさん
08/03/04 22:30:10
>>588
キャッシュが共有の場合は、キャッシュラインが同じでもOK。そのほうが効率よい。
キャッシュが分かれている場合は、同じキャッシュラインへの書き込みは最悪になる。MESIプロトコルで具具ってみよう。

592:デフォルトの名無しさん
08/03/05 13:50:16
URLﾘﾝｸ(journal.mycom.co.jp)
HTMって性能出るのかな。。

593:デフォルトの名無しさん
08/03/05 14:19:28
トランザクションメモリって、
JavaのAtomicReference#compareAndSetみたいなのじゃだめなの？

594:デフォルトの名無しさん
08/03/05 16:58:48
失敗したとき、その中でやったことは全部無しにしてくれるんだろうか?
>>593 良い場合もあるけど、例えば、複数のHashMapとかをatomicに操作したい場合は面倒じゃない？

595:デフォルトの名無しさん
08/03/05 23:18:48
マルチスレッドなくなってしまう。
今までがずっとCPUだと思っていたものは、実はスレッドなんで、。

596:デフォルトの名無しさん
08/03/06 02:46:25
Windowsでの条件変数実装の話題蒸し返したいので、俺の調査結果を晒してみる。

apr -> 再帰mutex非サポートぽい？簡潔過ぎるし、他にもバグあるだろ絶対。
yaneSDK3rd::LockObject -> すごく分かりやすい実装。再帰ロックしてのwaitにバグあり。修正は簡単。
boost::condition -> 複雑。完璧なのか？タイムアウト監視にシステム時刻使ってるのが嫌。

自前のC++ライブラリ構築して使ってるが、
yaneSDK3rdベースの実装からboostベースに交換してみようと思って
とりあえず、boost::xtime使ってる部分はGetTickCountに変えた。
システム時刻は某通信プロトコルでいつでも変更されてしまうので。
っつーか、clock()とかにもFILETIME使ってるのってどうなのよ･･･
boost実装に>>473のような問題が無いか検証しようとしてるが、
こいつのアルゴリズムは結構複雑で手強そうだ･･･
肝心のACEのソースはまだ読んでない。

597:デフォルトの名無しさん
08/03/07 02:19:24
条件変数の用途って
生産者/消費者的な使い方がかなりの部分を占めると思うんだけど、違うかな？
そういう用途のみに限れば、IOCP使えば充分なんじゃないのかね。
キューにデータがあるときはカーネルに行かないって言明されてるし。

598:デフォルトの名無しさん
08/03/08 02:15:16
無知を承知で聞くけど、ユーザーモードに限って言えば
普通はCriticalSection一択じゃないの？
CriticalSection自体がSpinCountの設定次第でカーネルモードにいかないようになってるから
そのチューニングで大体の用途には間に合うと思うんだが。

VistaだとRead/Writeロックが実装されたから、そっち使ったほうが早いかもしれんけど。

599:デフォルトの名無しさん
08/03/08 18:32:59
Windowsはあまり知らないんだけど、Enter/Leaveしか出来ないの？

600:デフォルトの名無しさん
08/03/08 19:25:08
TryLock もバージョンが↓でなければできる

601:デフォルトの名無しさん
08/03/16 09:31:31
VC++Windowsアプリの質問です。
メッセージループを１つのスレッドに隔離しようと思うのですが、
PostQuitMessage(0)を別スレッドから単純に呼び出しても安全でしょうか？

HWND g_hWnd
BOOL g_Active;

// g_Activeをクリティカルセクション内でやり取り
BOOL fGetActive();
VOID fSetActive(BOOL isActive);

INT WINAPI WinMain(...){
fSetActive(TRUE);
g_hWnd = (ウインドウハンドル作成);
メッセージループ用スレッド生成
while( fGetActive() ){
if(...) PostQuitMessage(0);
}
メッセージループ用スレッド後処理
return 0;
}
UINT WINAPI MessageLoop(...){
MSG msg;
msg.hwnd = g_hWnd;
while (GetMessage(&msg, NULL, 0, 0) > 0){
...
}
fSetActive(FALSE);
return 0;
}

602:デフォルトの名無しさん
08/03/16 11:40:27
サブスレッドからアプリケーションを直接終了させる設計は変じゃないか。
メインスレッドに何らかのメッセージを送って、メインスレッドからアプリケーションを終了すればよいじゃない。
面倒なら、少々強引だが、PostThreadMessageでメインスレッドに
直接WM_QUITを送りつけるのも。あまりお勧めしないが。

603:デフォルトの名無しさん
08/03/16 12:57:27
ウィンドウはそれを作ったスレッドに結びついているよ

604:デフォルトの名無しさん
08/03/16 13:10:12
>>601
PostQuitMessageを別スレッドから呼び出すことは問題ないけど、
メッセージは、ウィンドウの作成元のスレッドにしか来ないよ
別スレッドでGetMessageしたかったら、そっち側でCreateWindowしないとだめ

605:604
08/03/16 13:11:34
＞PostQuitMessageを別スレッドから呼び出すことは問題ないけど、
って、ウソでした、カレントスレッドにWM_QUITを送るだけか
PostThreadMessageで相手スレッドにWM_QUITを送ればいいかも

606:デフォルトの名無しさん
08/03/16 14:31:10
>>602-605
ありがとうございます。
MSG構造体へメッセージを送る際のデッドロックが心配でした。
>>602
＞サブスレッドからアプリケーションを直接終了させる設計は変じゃないか。
ウインドウモードだと×からも終了させる場合があるのと、
メインスレッドのID取得が難しそうなので変えられなそうです。

607:デフォルトの名無しさん
08/03/16 22:42:23
>メインスレッドのID取得
プログラム開始時にメインスレッドから GetCurrentThreadId を呼んで、
メインスレッドのIDが取得して、それをグローバル変数にでも入れておけば良いかも。

それがいやなら、メインスレッドにくくりついている非表示ウィンドウを一つ作っておいて、
そこに向かって PostMessage して、メインスレッドにメッセージをポストするのも手。
windowsではよくある話。

608:６０１、606
08/03/17 15:08:05
もう一つ質問させてください。
メインスレッドがウィンドウを持ち、GetMessageのループをしていてかつ、
サブスレッドがメインスレッドのウィンドウにDirect3Dで描画している場合、
GetMessageとDirect3DがHWNDへのアクセス権をもめてクラッシュしますか？

609:デフォルトの名無しさん
08/03/17 16:22:56
swapchainでググれ

610:デフォルトの名無しさん
08/03/17 17:00:28
サブスレッドでバックバッファに書き込んだ後、
メインスレッドにバッファを転送するべきという意味ですか？
うーん……

611:デフォルトの名無しさん
08/03/17 21:18:56
>>608
クラッシュしませんよ。
ただ、例外があって、ディバイスをリセットするときだけはディバイスを作成したスレッドからリセットを
コールしてあげないといけないからその点は注意。
メインスレッドでディバイスを作成した場合は、サブスレッドからはリセットは出来ない。

なので、もし、サブスレッドからディバイスをリセットする場合は、
まず、適当な自作ウィンドウメッセージをサブスレッドからメインスレッドのウィンドウに投げて、
メインスレッドのウィンドウがそれを拾ったらメインスレッド側から
ディバイスをリセットする。

612:デフォルトの名無しさん
08/03/18 21:47:01
Linux 2.6.21です
sigwait()しているスレッドに他のスレッドからpthread_cancel()を実行してもスレッドがキャンセルされません
sigwait()はキャンセルポイントのはずなのになぜ、と困惑しています
うちの環境のみなんでしょうか
もしくはLinuxの仕様？

613:612
08/03/19 07:24:50
すいません、自分の勘違いでした

614:デフォルトの名無しさん
08/03/25 19:48:12
すいません。教えてください。
linux 2.6.20でpthreadです。
sched_get_priority_minとsched_get_priority_maxで優先度の
最大値と最小値を得たところ両方０でした。
これは優先度を選択できないということでしょうか。
優先度の最大値、最小値を得るのに使った引数は
sched_getscheduler(getpid())で値は０でした。
よろしくおねがいします。
あ、あと書き忘れましたがlttng0.9.0のパッチを当ててます。

615:デフォルトの名無しさん
08/03/25 20:06:05
>>614
URLﾘﾝｸ(www.linux.or.jp)
＞Linux　では　SCHED_FIFO　と　SCHED_RR　では　1　から　99　の範囲の静的プライオリティーを持ち、
＞SCHED_OTHER　と　SCHED_BATCH　ではプライオリティとして　0　を持つ。

616:614
08/03/25 21:04:25
ありがとうございます。
優先度を指定しよう思ったらSCHED_FIFOかSCHED_RRにしろということですね。
考えて見ます。

617:デフォルトの名無しさん
08/03/26 02:52:53
RTの付いたカーネルじゃないとダメじゃなかったっけ？

618:デフォルトの名無しさん
08/03/31 00:04:13
Numaで確保した共有メモリ内に
pthread mutext仕込むと
Numaで共有しているマシン間で
排他取れるの？

619:デフォルトの名無しさん
08/03/31 13:08:46
出来ないの?

620:デフォルトの名無しさん
08/03/31 22:36:00
教えてくれよｗ

621:デフォルトの名無しさん
08/04/01 07:07:46
POSIX準拠なら取れないとおかしいという結論になるはず。
「NUMAで確保したの共有メモリ」がPOSIX準拠かどうかまでは知ったこっちゃねぇ。

622:デフォルトの名無しさん
08/04/01 16:27:39
もし出来ないなら、アドレス空間が共有できてもうれしくないと思うんだが。
割と普通なOpteron複数搭載機ではまる人が続出しそう。

623:デフォルトの名無しさん
08/04/09 23:10:05
URLﾘﾝｸ(docs.sun.com)

この関数ってなんか役に立つの？

624:デフォルトの名無しさん
08/04/10 00:11:50
？？

625:デフォルトの名無しさん
08/04/10 00:19:17
>>623
リード側と書き込み側の間でブロックしにくくなるんじゃないかな？

626:デフォルトの名無しさん
08/04/10 00:37:03
>>625
じゃあmutexでおｋ？

627:デフォルトの名無しさん
08/04/10 05:29:38
？？

628:デフォルトの名無しさん
08/04/10 09:01:57
read同士でblockしない点が有用。

629:デフォルトの名無しさん
08/04/10 10:00:18
あるデータAをRWロックでブロックしてるとする

スレッド１がAを読み込もうとしてるときに・・・

スレッド２がAを読み込むことがある
スレッド３がAを書き込むことがある

となっている２つの場合を考える

もしスレッド１と２のみであれば、Aの値は不変のはずだから
１が処理中でも２は処理できる。
つまりRead同士ではブロックする必要がない

しかし、１と２が処理中に３が処理しようとするとおかしくなる。
だから読み込み同士ではブロックないが
書き込みはブロックしないといけない。
これがReadロック。

逆に、３が動いているときに、１と２が読み込もうとしている場合は
３が終わるまでは１も２も読み込んではいけない。
スレッド４が書き込みをしようとしてたとして、これも当然ブロックしないといけない。
つまり排他処理するのがWriteロック。

これをMutexに置き換えると、Read同士でブロックしてしまう可能性があるので
その頻度によってパフォーマンスが落ちることが考えられる。
しかし、とりあえず動かすことが重要であれば、置き換えるだけでも動く。

630:デフォルトの名無しさん
08/04/12 12:43:28
マルチスレッドで仕事量分割するための
手法説明している本ってないっすか？

631:デフォルトの名無しさん
08/04/12 15:24:51
VC6でマルチスレッドのアプリ作ってるんだがトラウマになりそうだ

632:デフォルトの名無しさん
08/04/12 22:27:49
マルチスレッド間で
カスタムメモリアロケタ君を
書きたいけど基本的なロジックとか
みんな何参考にしてるの？

633:デフォルトの名無しさん
08/04/13 23:00:37
すみません。

デバッグ中に、CPU帯域を独占してるスレッドを特定したいのですが。
なにかいい方法はありませんか？

開発環境はVisualStudio2005で言語はVC++です。

634:デフォルトの名無しさん
08/04/14 00:02:22
パフォーマンスモニタでスレッドＩＤごとの負荷率が出る。
スレッドIDはデバッガで一時停止のスレッドで見られる

635:デフォルトの名無しさん
08/04/14 00:17:59
>>634
ありがとうございます。
特定できました。

636:デフォルトの名無しさん
08/04/18 07:54:17
>>635
特定しました。

637:デフォルトの名無しさん
08/04/18 14:08:38
特定しますた

638:デフォルトの名無しさん
08/04/18 22:40:16
lock-freeアルゴリズムの
検証方法教えてくれよ

どうやって正当性保障するんだよｗ
あれ難しすぎだ

639:デフォルトの名無しさん
08/04/20 18:56:56
SPINみたいなのを使うんだろうか？

640:デフォルトの名無しさん
08/04/20 23:36:09
volatileで十分

641:デフォルトの名無しさん
08/04/21 00:52:23
原論文に検証あるだろ？

642:デフォルトの名無しさん
08/04/21 21:53:58
それが理解できないから、易しく解説して

って言う話じゃないのかな。

643:デフォルトの名無しさん
08/04/21 22:43:36
数式での検証と
実装の検証は違うと思うのは俺だけｗ？

俺は頭が悪いんだろうなｗ

644:デフォルトの名無しさん
08/04/21 23:37:15
うん、頭が悪い。

「プログラムの正しさの証明」って言われて、
この証明が数学で言う証明のことだと理解できないタイプ。

645:デフォルトの名無しさん
08/04/22 07:35:55
実用性ない数式出されてもなぁ
後から付帯条件つきまくる数式
出されてもなぁ

646:デフォルトの名無しさん
08/04/22 09:36:27
マジで頭悪そう

647:デフォルトの名無しさん
08/04/22 22:16:26
ここも過疎ってるよなぁｗ

648:デフォルトの名無しさん
08/04/23 08:00:42
一覧に無いからだと思うあげ！

649:デフォルトの名無しさん
08/05/02 17:43:24
自作板にいるキチガイです。シングルスレッドで作成されてるソフトが
カーネルによってマルチコアにスレッド（タスクのことか？）が分散されると申しております。
このＩＤだけの発言では分かりにくいが、このスレにはシングルスレッドでもマルチコアのほうが早いと
のたまわってるキチガイがいます。
まだまだシングルCPUで頑張る人集合
ｽﾚﾘﾝｸ(jisaku板)

800 Socket774 sage New! 2008/05/02(金) 08:31:32 ID:Aaj/7HlH
このスレのシングルコアユーザーは未だにWindows3.1を使ってるようだｗ
801 Socket774 sage New! 2008/05/02(金) 08:32:49 ID:Aaj/7HlH
プログラムのスレッドと
CPUが処理する単位のスレッドは
意味が違うｗ
802 Socket774 sage New! 2008/05/02(金) 08:42:42 ID:Aaj/7HlH
プログラムのスレッドはカーネルによってさらに細分化される
与えられたCPUタイムによってそれを１つづつ実行していく
大まかに２ブロックに分割されたとしよう
１コアが１ブロックを実行してCPU使用権が終了する
その時に２コアが暇をしてるので２ブロックに即座に使用権が渡される
つまり単純に２倍の処理性能になる
806 Socket774 sage New! 2008/05/02(金) 10:52:29 ID:Aaj/7HlH
いやだからマルチスレッドOSって時点で
実際のCPU利用率は半分以下なんだよ
どんだけがんばってもそうなの
シングルコアだったら１００％使えるとかないからｗ
コアが２になるとより１００％に近い状態になるわけ
一般に１．８倍だと言われる
MS-DOSやWindows3.1を使ってる人はシングルコアのが早いかもねｗｗｗ
807 Socket774 sage New! 2008/05/02(金) 10:57:04 ID:Aaj/7HlH
>>803
ベンチマークのような単純処理の繰り返しではスレッドの細分化はほとんど行われない
ゲームみたいな大きなスレッドになると実際に４倍近くの性能を発揮する

次ページ