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

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

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
ベンチマークのような単純処理の繰り返しではスレッドの細分化はほとんど行われない
ゲームみたいな大きなスレッドになると実際に４倍近くの性能を発揮する

650:デフォルトの名無しさん
08/05/02 17:51:33
>>649
頭のおかしな人というのはある程度の確率で常にあらわれるものであって、
そういう人がいるのはおかしいとか、説明して頭をよくしてあげよう等の考えは
全くの無駄だと思う。中身の入って無い枝豆同様ハズレとして無視するよりない。
いらいらする気持はわかるけどね。

651:デフォルトの名無しさん
08/05/02 17:52:33
コピペ君に応答する奴も馬鹿だな、まで読んだ。

652:デフォルトの名無しさん
08/05/02 19:14:41
osのタスク切り替え戦略によってはそうなるかもしれないけど、
普通は強制的な一定タイムスライスじゃないよね。
システムコール待つのにビジーウェイトでもしてると思ってんのか。

653:デフォルトの名無しさん
08/05/02 20:14:27
ほかのタスクや割り込み処理に割り込まれる可能性が減る（ほかのＣＰＵに割り振られる）から
「遅くなりにくい」ということはいえるが
速くなることはないだろうなあ。

って件のスレで当人書いてるじゃん

654:デフォルトの名無しさん
08/05/02 21:56:31
1coreの時にOS側のタスクによるオーバヘッドが1%程度あったとすると
2coreならアプリの実行時間が1%短くなる程度なら有り得る

655:デフォルトの名無しさん
08/05/03 06:58:19
ゲームでならDirectSoundは別スレッドで動いてるので
もうちょっと効果あるかもね。

656:デフォルトの名無しさん
08/05/03 08:29:25
例えばX11だと描画はサーバプロセスが行なうから結構効果がありますね。
でもそれをシングルスレッドアプリが速くなると言ってしまうとちょっと違うと思いますが。

657:デフォルトの名無しさん
08/05/03 08:33:56
よっぽど単純なプログラムでもない限り
完全なシングルスレッドなんてあり得ないんですけどねｗ

658:デフォルトの名無しさん
08/05/03 08:40:56
たとえばEXCELで
再計算処理が行われてる時にメニューを実行すると
再計算、描画、メニューの３つのスレッドが形成される

659:デフォルトの名無しさん
08/05/03 08:47:38
ビス太のユーザーランドスレッドの方針を分かって話してるの？

660:デフォルトの名無しさん
08/05/03 12:26:31
スレッドプールのはなし？

661:デフォルトの名無しさん
08/05/03 15:17:42
>>658
スレッドが生成されるかどうかと
並行実行するかどうかは別だぞ

662:デフォルトの名無しさん
08/05/03 18:15:41
OpenMP中で使ってるとか
そんなんじゃねーのｗ

663:デフォルトの名無しさん
08/05/03 19:22:28
>>661
XPでは平行実行してるが？

664:デフォルトの名無しさん
08/05/03 19:59:25
>>663
させるかどうか、だ

665:デフォルトの名無しさん
08/05/03 23:51:43
シングルスレッドでコンパイルするやつはいないだろｗ

666:デフォルトの名無しさん
08/05/04 00:40:42
それまでの話の流れとは関係ないが

「マルチスレッド対応ライブラリを使用する」と
「マルチスレッドで動作するプログラムにする」は全く違うのだが
まさかとは思うが、>>665はそういう意味じゃないよな？
当然、「コンパイラをマルチスレッドで動作させる」だよね？

一応触れておくと
Win32で普通にGUIプログラムを作る場合、明示的にスレッド関連の操作をしない限り
マルチスレッドで動くことは無い。
何故なら、メッセージキューが１スレッドに１つ作られるので
そこからのイベントで処理を記述する書き方だと、１スレッドにしかならないから。
(イベントハンドラでスレッド操作をすれば当然マルチスレッドも可能)
もちろん、カーネル内の処理(割り込み等)は別。

667:デフォルトの名無しさん
08/05/04 00:59:30
そういえば、Win9xのWinsock2の非同期処理は
内部的にスレッド作って擬似動作させてたんだっけ。
忘れてた。

668:デフォルトの名無しさん
08/05/04 01:14:13
>>666
メッセージキューも明示的に作る(作らせる)ものであって
スレッド作成=メッセージキュー作成じゃないよ。

669:デフォルトの名無しさん
08/05/04 12:10:33
> メッセージキューも明示的に作る(作らせる)ものであって

具体的にどうやって作るの？

670:デフォルトの名無しさん
08/05/04 12:39:33
MSDNのPostThreadMessageの所に書いてあるな

671:まあ、明示的がどうかは人によって違うと思うが...
08/05/04 16:07:57
これのことかな...

> その後、ポスト先のスレッドで、
> PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE) を呼び出し、
> このスレッド用のメッセージキューを強制的に作成します。

でもこれって、

> スレッドが Win32 のユーザー関数または GDI 関数のいずれかを最初に
> 呼び出した時点で、システムはそのスレッドのメッセージキューを作成
> します。

ってことだよね。

あまり「明示的」とは思えないんだが...。

672:デフォルトの名無しさん
08/05/04 17:10:13
風が吹いたら桶屋が儲かるくらい暗黙的でなければ明示的

673:デフォルトの名無しさん
08/05/04 22:53:30
いや別にメッセージループに入ったからといって
CPUを最後まで占有出来るわけじゃないのだ
途中で強制的に割り込まれる
そうすると他のループに権利が渡されるだけだな
マルチスレッドでコンパイルすると各メッセージループは完全に独立したスレッドになる
だから既存のアプリもほとんどはデュアルコアの恩恵がある

674:デフォルトの名無しさん
08/05/04 23:11:24
おまえはそんなにメッセージループを作っているのか？

大多数のアプリはWinMainの中のGetMessage１つだけだと思うが

675:デフォルトの名無しさん
08/05/04 23:12:03
それと、「マルチスレッドでコンパイルする」の意味を具体的に説明しろよ

676:デフォルトの名無しさん
08/05/04 23:14:14
上の方は、プリエンプティブマルチタスクの解説で、4行目の
「他のループ」＝「他のプロセスのメッセージループ」なのかなー
と思って読んでいたが

＞マルチスレッドでコンパイルすると各メッセージループは完全に独立したスレッドになる

え？

677:デフォルトの名無しさん
08/05/05 00:56:45
ちょっぴりエスパー能力を発揮して解読してみた。

普通、「メッセージループ」と言うと
while (GetMessage()) { ... } の部分のことを指すと思うのだが
おそらくこのヒトは、DispatchMessageで間接的に呼ばれるルーチン、
大抵は「WndProcの呼び出し１回」のことを
「メッセージループ」と呼んでいるような気がする。

678:デフォルトの名無しさん
08/05/05 01:18:24
だとしてもウインドウプロシージャがマルチスレッドで
並列実行されたりはしないと思うが。

679:デフォルトの名無しさん
08/05/05 01:48:05
もちろんその通り。

大丈夫、基本的な仕組みを理解してないのは、多分一人だけだから。

680:デフォルトの名無しさん
08/05/05 03:39:24
え？　そうなん？
メッセージループをマルチスレッドでコンパイルしたら
完全にプリエンプティブなマルチコアになるでしょ

681:デフォルトの名無しさん
08/05/05 05:18:58
だからその「マルチスレッドでコンパイル」って、何をどうすることなの？

682:デフォルトの名無しさん
08/05/05 05:34:27
一応、>>666の前半部に、候補としていくつか挙げてあるけど
・マルチスレッドライブラリを使用する(コンパイラオプションを設定)
・マルチスレッドで動作するようにソースコードを書き換えてコンパイルし直す
・コンパイル時にコンパイラがマルチスレッドで動作するオプションを使う(対応しているもののみ)
・その他

ところで、「プリエンプティブなマルチコアになる」って何？
「マルチスレッドでコンパイルする」「メッセージループがスレッドになる」に続いて
またまた第三者からは理解不能な言葉が出て来てるんですけど。

683:デフォルトの名無しさん
08/05/05 05:37:36
>>680
これは釣りだろ

684:デフォルトの名無しさん
08/05/05 06:45:01
「マルチスレッドでコンパイルする」

そういえばVS2005から並行コンパイルができるようになったけど
そのことかな。

685:デフォルトの名無しさん
08/05/05 08:03:25
>>683
知ってる単語を並べただけと言う疑惑も捨てがたい。(w

686:デフォルトの名無しさん
08/05/05 10:57:32
データを完全にシーケンシャルに
処理する必要があるのに
スレッドの接続形態が

1-N-1って場合って

どんな利点があるの？キュー作っても処理遅くなるだけじゃね？

687:デフォルトの名無しさん
08/05/05 11:26:27
メッセージの元になるイベントは、システム全体に対して非同期に起こるんだよ。
おまいのアプリ上だけじゃないし、処理終了を待って定期的に起こるわけでもない。

688:デフォルトの名無しさん
08/05/05 14:20:25
マルチスレッドでコンパイルする=MTsafeにするだろう

689:デフォルトの名無しさん
08/05/05 15:24:34
>>686
ここの人には「完全にシーケンシャル」の意味するところがわからないから、
その形態作った奴に聞いてみればいいんじゃね。

690:デフォルトの名無しさん
08/05/05 17:14:57
よくわからないけど、入力1、処理N、出力1みたいな感じだとすると、
最後の1を遊ばせないためには良いんじゃないかという気がする。
まあ何やるか次第だけど。

691:デフォルトの名無しさん
08/05/05 17:16:08
>>690
でもめちゃくちゃ排他制御かからないかなぁ？
常にシーケンシャルってことは前のデータ待って
処理しないといけないってことだろうし

692:デフォルトの名無しさん
08/05/07 11:17:48
コンパイラオプションのシングルとMTが具体的に何をしてるのかは知らないが
MTにした時に各イベントは完全に非同期で発生する
並列実行してるのだと思ってるのだが違うのか？

693:デフォルトの名無しさん
08/05/07 11:46:10
いいえ。イベント発生は非同期ですが、受信が並列に行われる保証はありません。
# つーか、並列実行できるくらいならイベント機構はもっと簡略化できるわけで。

694:デフォルトの名無しさん
08/05/07 13:47:11
>コンパイラオプションのシングルとMTが具体的に何をしてるのかは知らないが
コンパイラのヘルプ読めよ・・・

695:デフォルトの名無しさん
08/05/07 17:24:03
マルチスレッドでコンパイルといえばマルチスレッド実行されるのが当然だろ
何言ってるんだか

696:デフォルトの名無しさん
08/05/07 21:18:32
・マルチスレッド (対応のコンパイラ) でコンパイルといえば
　(コンパイラが) マルチスレッド実行...

・マルチスレッド (オプションをつけた状態) でコンパイルといえば
　(生成されたプログラムが) マルチスレッド実行...

日本語難しいアルネ。

697:デフォルトの名無しさん
08/05/07 22:05:44
最近のコンパイラはマルチスレッドで動作するプログラムを勝手に生成してくれるの？

698:デフォルトの名無しさん
08/05/07 22:07:56
MT対応ライブラリをリンクするだけじゃね
OpenMPとか一応あるけど明示的にディレクティブを書かないといけないし

699:デフォルトの名無しさん
08/05/07 22:13:13
それはライブラリの使い方次第だろう。
MT-safeになるだけっていうのとはまた違うし。

なんかレベルがよく分からない抽象的な話しかないのは気のせいか。

700:デフォルトの名無しさん
08/05/07 22:27:00
>>697
コンパイラ自体は何もしないけど
MFCとかのフレームワークがするんでしょ

701:デフォルトの名無しさん
08/05/07 22:32:49
私はいつものようにMFCでプログラムを組んでいた
当然のごとくMTをコンパイラオプションに指定した
ある日、子ウィンドウから親ウィンドウにある関数を実行する必要性が出てきた
私はPostMessageでオリジナルのイベントを実装することを思いついた
そこには処理Aと処理Bという２つの関数が存在した
処理Bは処理Aの結果を利用するものである
処理B単体で実行する場合もあるのでこの２つは独立していた
私は当然のごとく各イベントはシーケンスに処理させるのだと思い込んでいた
メッセージA、メッセージBと順番に親ウィンドウに送信する
するとどうだろうか
プログラムは例外エラーを発生させて画面から消えるではないか
私は挙動を調べるべく調査に乗り出した
そしてついにその原因を突き止めた
この２つの処理は同時に実行されている

702:デフォルトの名無しさん
08/05/07 22:42:19
非同期のPostMessageじゃなくて同期のSendMessageだったっけ、そういうのなかった?
winapiから遠ざかりすぎてﾜｽﾚﾀ。非同期メッセージ通信なのだから、
>各イベントはシーケンスに処理させる
って前提は、キューに入れられた順番はあるけど
cpuが空いていればキューから取り出してすぐに実行されるってこと?

703:デフォルトの名無しさん
08/05/07 23:01:41
内部的にSendMessage使ってる関数でデッドロックしたことがあるのでマルチスレッド怖い

704:デフォルトの名無しさん
08/05/07 23:05:04
デッドロックはアナライザで一発で見つかるから楽。
問題はコンディションレースだ。

705:デフォルトの名無しさん
08/05/08 09:27:46
>>701
MFCをコンパイルするときは/MLオプションを
受け付けなかったと思ったがどうだっただろう。
/MD　と　/MTの切り替えは問題なく出来るはず。
さらにVS2005からは/MLは廃止になっている。

一応説明しておくと
/MLはシングルスレッド用CRTライブラリのスタティックリンク
/MTはマルチスレッド用CRTライブラリのスタティックリンク
/MDはMSVCRT.DLL（版によって名称の差異あり）へのダイナミックリンク

706:デフォルトの名無しさん
08/05/08 11:54:00
メッセージキューは必要に応じてスレッドごとに生成される。
自他スレッドやOSから発行されるウインドウメッセージはメッセージキューで並列化され、
メッセージループで読み出されることによってその後のウインドウプロシージャの処理は
メッセージループのスレッドで実行される。
つまりマルチなのはキューまでで後は単一のスレッドで実行される。

ただし単純にシーケンシャルに実行されるわけではない。
キューはプライオリティキューであり順番が入れ替わることがある。
ウインドウプロシージャ内でメッセージキューに関係する命令を使った場合、
現在のメッセージの処理を一旦中断し別のメッセージに実行権を譲渡することがある。
>>701はこの辺を並列で実行されたと誤認してるものと思われる。

どうしてもマルチで動作してると言い張るつもりなら、
ウインドウプロシージャにスレッドIDの変化を調べるルーティンを入れて
変化が認められるか調べるのが一番だと思う。

707:デフォルトの名無しさん
08/05/08 12:34:36
>>706
2行目訂正
誤）メッセージキューで並列化され
正）メッセージキューで直列化され

708:デフォルトの名無しさん
08/05/08 12:41:26
>>701
新しいスレッドを作らない限り同時に実行は無いよ。もっとよく調べてみよう。

709:デフォルトの名無しさん
08/05/08 13:18:51
WndProcがマルチスレッドに動くなら
そこらじゅうMutexやらCritical　Sessionだらけになる予感
もちろんVolatile論争もこのスレ的にOK

710:デフォルトの名無しさん
08/05/09 15:43:52
同期コストで逆に遅くなりそうだな。

711:デフォルトの名無しさん
08/05/11 21:24:19
どうせCSocketみたいな内部でPeekMessageで回してるのを見て
同時実行されてると思い込んでるだけでしょ。

712:デフォルトの名無しさん
08/05/13 20:18:26
何の技術もないんですが、気になってることを質問させてください。
マルチコアプロセッサでマルチスレッドのプログラミングをする時って
スレッドを、ポンポンって作って、後はOSとかが暇にしてるコアに
仕事を割り振ってるんですか？
それとも、プログラムの側で、「この処理はお前がやれ」ってマルチコアの
特定のコアに指定して割り振るんですか？

調べてみたら、どうも前者っぽいんですが、気になって昨夜は2時間くらい
布団の中で寝れませんでした。お願いします、教えてください。

713:デフォルトの名無しさん
08/05/13 20:25:47
>>712
何も指定しなければOSが自動的に割り振る。
指定すれば割り振ることができる。
だからどっちともいえる。

714:デフォルトの名無しさん
08/05/13 20:31:19
>>713
ありがとう。これで今夜はゆっくり寝れる。
もうひとつ聞きたいこと出てきました。
指定する場合ってどうやるのか、キーワードだけでも
教えていただけると有り難いです。

715:デフォルトの名無しさん
08/05/13 21:06:27
affinityでググればいいんじゃね

URLﾘﾝｸ(www.linux.or.jp)
こんなんとか
URLﾘﾝｸ(msdn.microsoft.com)

716:デフォルトの名無しさん
08/05/13 21:15:44
>>715
あーりーがーとー。
いろんなキーワードで調べてたけど
ずっと見つからなかったものが、ようやく見つかった。
感謝します。

お邪魔しました。

717:デフォルトの名無しさん
08/05/13 22:40:13
>>716
Linuxだとtasksetってコマンドで簡単に設定できるので便利。

718:デフォルトの名無しさん
08/05/13 23:52:00
>>717
おぉ。寝る前に念のためにきてみたら、またいいこと知った。
ありがとねー。

719:デフォルトの名無しさん
08/05/21 17:41:08
質問させて下さい。
WindowsでGUIから何らかのアクションでスレッドを起動し、
ESCキーを押下でメッセージボックスを表示して、
スレッドの実行を中止できるようにしたいと考えています。
こんな風に↓

case IDM_KEY_ESCAPE: {
　if (thread.suspend()==0) {
　　if (MessageBox(hwnd, "", ""),MB_OKCANCEL)==IDOK) { thread.terminate(); }
　　else { thread.resume(); }
　}
　break;
}

で、以下のようなスレッドクラスを作成しました。
（つづきます）

720:719
08/05/21 17:42:31
class Thread {
　HANDLE hthread_;
　unsigned int id_;
　void run(void) { /* 具体的な処理 */ }
public:
　void start(void) { hthread_ = (HANDLE)_beginthreadex(NULL, 0, Thread::entrypoint, this, 0, &id_); }
　DWORD suspend(void) const { return SuspendThread(handle()); }
　DWORD resume(void) const { return ResumeThread(handle())); }
　static unsigned int WINAPI entrypoint(void* instance) {
　　thread_t* p = static_cast<thread_t*>(instance);
　　p->run();
　　_endthreadex(0);
　　CloseHandle(p->handle());
　　p->hthread_ = 0;
　　return 0;
　}
};

721:719
08/05/21 17:43:00
しかし、実際に使ってみたところ、ESCキーでメッセージボックスを表示すると、
たしかにスレッドの処理は中断するのですが、
タスクマネージャを見ると中断している間も実行メモリが数KBずつ増えていくのです。
それで中断したまま（メッセージボックスを表示したまま）しばらく放っておくと、
タスクマネージャに表示された該当プロセスのスレッド数が１つ減ります。
（つまりGUI起動時のスレッド数になる）
そこでメッセージボックスのOKを選択してスレッドを終了すると、
さらにスレッド数が１つ減って、壊れた振る舞いをするという具合です。

とりあえずスレッドクラスについて質問したいのですが、
↑は変な実装ではないでしょうか？それから使い方も問題ないでしょうか？

OS:Windows Vista x64
言語:C++
環境:Visual Studio 2008

722:719
08/05/21 17:46:25
すみません。>>720のthread_tはThreadの間違い、
p->handle()はp->hthread_、それからterminateメソッドが抜けていました。

void terminate(void) {
　TerminateThread(hthread_, 0);
　CloseHandle(hthread_);
　hthread_ = 0;
}

}

723:デフォルトの名無しさん
08/05/21 18:09:32
TerminateThreadで終わらせたとき、run内で動的に確保されていたリソースはどうなるでしょうか。
それと、entrypoint内_endthreadex(0)の後に記述した処理は実行されないと思うのですが。
あとは知らん。

724:719
08/05/21 18:18:12
>>723 どうも。_endthread(0)でスレッドを終了したら、
自動的にentrypointから抜けてしまうのでしょうか？この辺、自信ありません。
（entrypointから抜けるときに_endthreadが呼ばれるというのはMSDNに書いてありましたが…）
あとrun内でのメモリの確保は全部boost::shared_ptrを使ってるので問題ないと思います。

いずれにしてもsuspend中に問題が発生しているわけで…。

725:デフォルトの名無しさん
08/05/21 18:25:16
mallocの中でsuspendしたら･･･とか思うと怖いな
何が起きても不思議ではない気がする

726:デフォルトの名無しさん
08/05/21 18:50:00
>>722
TerminateThreadの説明読んだ？
こんなおっかねーAPI俺は使ったことないぞ。
強制終了に相当する処理だよ。後始末なんか何もしない。

727:719
08/05/21 18:59:04
TerminateThreadが危険というのは知識としては知ってますが、
そこに至る前のSuspendThreadの時点で問題が起きているようです。
仮にメッセージボックスでキャンセルを選んで、
TerminateThreadではなくResumeThreadを呼んだ場合でも処理が壊れるのです…。

728:719
08/05/21 19:03:28
>>725
スレッド内で動的にメモリを確保するのは一般的なことだと思うのですが、
その場合にSuspendThreadを呼ぶタイミングが問題になるなら、
Suspend/ResumeThreadというのはものすごく使いにくい関数な気が。

729:デフォルトの名無しさん
08/05/21 19:04:04
TerminateThread()とか_endthreadex()は、
「呼ばれたらスコープを抜けてローカル変数の解体処理をして…」
なんてことは、一　切　や　っ　て　く　れ　ま　せ　ん　。
稼動中のPCの電源を無造作に切るかのようにスレッドの処理を打ち切ってくれます。
shared_ptrのデストラクタなんか呼ばれるわけが無いので、メモリリーク必至です。

で、知っているくせに何でそんなふざけたコード書いてんの？

730:719
08/05/21 19:08:11
>>729
あ、デストラクタも呼ばれないんですか。それは知りませんでした。勉強になりました。
で、なんでこういうコードを書いているかというと、
危険だというTerminateThreadを何に置き換えるかは後で考えるとして、
とりあえずSuspend/Resumeの部分を実装するために書いたコードなわけで。

731:デフォルトの名無しさん
08/05/21 19:11:12
>>728
そーだよ。
例えばクリティカルセクションに入ったまま止めてしまったら、再開させるまで他のスレッド入れなくなるわけだし。

あと、これ。
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
＞This　function　is　primarily　designed　for　use　by　debuggers.
＞It　is　not　intended　to　be　used　for　thread　synchronization.

732:719
08/05/21 19:19:42
>>731
なるほど。その"This function is ..."の１文でいろいろ吹っ切れた気が…。

Suspend/Resumeの機能を実装したければ、外からスレッドに何かシグナルを送って、
スレッド自らの手でSuspendする必要があるわけですね。
SuspendThreadはその部分をよきに計らってくれるものだと勘違いしていました。
どうもありがとう～。

733:デフォルトの名無しさん
08/05/21 19:32:28
まあ精進してちょ。

734:デフォルトの名無しさん
08/05/21 21:23:54
ふつーはイベントを待つ。

735:デフォルトの名無しさん
08/05/25 07:53:30
グローバルにスレッド管理用のフラグを用意する
スレッド起動時にこのフラグを１にセット
スレッド内で定期的にこのフラグを監視し０になったら途中で終了する
メッセージボックスでキャンセルされた時はこのフラグを０にするだけ

736:デフォルトの名無しさん
08/05/25 08:00:05
マルチスレッドだとスタック領域が別になるから
グローバルで取ったフラグ用変数のポインタをスレッドに最初に渡すのだよ

737:デフォルトの名無しさん
08/05/25 08:02:38
別にクラス内のローカルな変数でもいいんだけどね
その時はクラスのポインタを渡すのだよ
クラス定義を組み込むのを忘れないでね

738:デフォルトの名無しさん
08/05/25 10:51:14
あとvolatileも

739:デフォルトの名無しさん
08/05/25 11:47:42
c/c++のvolatileはいろいろあるから、
ちゃんとmutexなどの同期オブジェクトを使うことをすすめる。
ただwindows限定ならvolatileにメモリバリアの意味があるのだっけ？

740:デフォルトの名無しさん
08/05/25 13:03:14
> c/c++のvolatileはいろいろあるから、
> ちゃんとmutexなどの同期オブジェクトを使うことをすすめる。

もしかして volatile 変数で同期とろうとか思ってる？

741:デフォルトの名無しさん
08/05/25 13:08:25
荒れる予感

742:デフォルトの名無しさん
08/05/25 13:10:20
>>739
メモリバリアの意味はない。
ただ、IA32はコヒーレントキャッシュだから、volatileだけでも
大して問題がないだけ。

743:デフォルトの名無しさん
08/05/25 13:18:53
ていうかこのケースは知らないが

もし「ループを一周余分に回すことになっても問題ない」という
厳密な同期が必要ないものならば、volatileで済むケースはある。
そんなに多くは無いが。

744:デフォルトの名無しさん
08/05/25 13:34:51
＞もし「ループを一周余分に回すことになっても問題ない」という
＞厳密な同期が必要ないものならば、volatileで済むケースはある。

むしろ今回のケースでは一周分余分に回すのがアウトという状況が考えにくい。

745:デフォルトの名無しさん
08/05/25 14:46:29
一周分余分に回ってアウトなら最初から排他なりセマフォなり入れるしな

746:719
08/05/25 16:06:04
結局↓のようなクラスにしました。今のところ問題ありません。

class Thread {
　HANDLE hthread_, hevent_; unsigned int id_; bool cancel_;
　void run(void) { while (1) { /* 具体的な処理 */ if (cancel_check()) { return; } } }
public:
　Thread(void) : hevent_(CreateEvent(NULL, TRUE, TRUE, NULL)), cancel_(false) {}
　~Thread() { CloseHandle(hevent_); }
　void start(void) { hthread_ = (HANDLE)_beginthreadex(NULL, 0, Thread::entrypoint, this, 0, &id_); }
　void cancel(void) { cancel_ = true; SetEvent(hevent_); }
　void suspend(void) { ResetEvent(hevent_); }
　void resume(void) { SetEvent(hevent_); }
　bool cancel_check(void) {
　　if (cancel_) { cancel_ = false; return true; }
　　WaitForSingleObject(hevent_, INFINITE); return false;
　}
　static unsigned int WINAPI entrypoint(void* instance) {
　　thread_t* p = static_cast<thread_t*>(instance);
　　p->run(); CloseHandle(p->hthread_); p->hthread_ = 0;
　　return 0;
　}
};

747:デフォルトの名無しさん
08/05/25 16:37:42
run()内で例外投げられたらまずくね

748:デフォルトの名無しさん
08/05/26 03:02:25
>>742
ダウト

749:デフォルトの名無しさん
08/05/26 03:25:49
kwsk

750:デフォルトの名無しさん
08/05/26 03:27:13
OoOの問題じゃないかなと思ったり。

751:デフォルトの名無しさん
08/05/26 13:30:52
UOがどうしたって？

752:匿名
08/05/30 15:12:16
スレッドは非常に難しいです。
スレッドを利用しないでコンカレントプログラムが容易にできます。
以下のページが参考になります。

URLﾘﾝｸ(www.cspjapan.org)

753:デフォルトの名無しさん
08/05/30 15:57:17
ばか？

754:デフォルトの名無しさん
08/06/05 15:10:05
生成したスレッドがmallocをしている最中に
SuspendThreadするとどんな問題が発生しますか？

755:デフォルトの名無しさん
08/06/05 15:26:07
mallocの中で排他制御しているだろうから、他のスレッドがmallocを呼
ぶと返ってこなくなるかも。

756:デフォルトの名無しさん
08/06/05 15:27:38
mallocがマルチスレッド対応版だと仮定すると、
ヒープ管理データへのアクセスの排他のために
mutexを握るタイミングがあるはず

そのタイミングでSuspendされると
ほかのスレッドがmalloc/free関連の処理をしようとして
mutex握れなくてずっと待ちに入る
newがmallocをベースにしているならnew/deleteも

はたから見るとハングアップに見える

757:デフォルトの名無しさん
08/06/05 22:23:21
>739
C#のvolatileはメモリバリアの意味もあるよ。
C/C++じゃないよ。

758:デフォルトの名無しさん
08/06/05 22:32:43
ふ～ん

759:デフォルトの名無しさん
08/06/07 21:41:57
MSDNのSystem.Threading.Thread.MemoryBarrierの説明が微妙でわかりづらい

＞MemoryBarrier　は、複数の　Intel　Itanium　プロセッサを使用しているシステムなど、
＞ウィーク　メモリ　オーダリングを採用したマルチプロセッサ　システムでだけ使用します。

760:デフォルトの名無しさん
08/06/07 23:24:59
memory orderingの知識がないだけじゃね？
strong memory orderingのx86では不要。
シングルプロセッサ(1コア)のシステムでも不要。
weak memory orderingのItaniumを複数使ったシステムでは必要。
書いてあるとおりｗ
memory orderingはこれでも読んどけ
URLﾘﾝｸ(www.arch.ce.hiroshima-cu.ac.jp)
x86はSPARCのTSOと、ItniumはSPARCのRMOと同じはず

761:デフォルトの名無しさん
08/06/08 00:21:36
質問しようと思ったら>>746に俺が・・・
この場合だとentrypoint内でCloseHandleしてreturn完了後にendthreadex呼ばれるという
挙動であってるのかな？で、ハンドルも問題なく閉じられるのか？

762:デフォルトの名無しさん
08/06/08 05:09:09
>>746は無茶苦茶だろ。
とりあえず思ったこと。
　・startで生成したhthreadを別のスレッドでcloseするのが変。
　　代入前にサブスレッドが終了したらアウチ
　・startが２回呼び出されたときのガードは当然してるよな
　・とりあえずcancel_はvolatileにしとけ。即座でなくても
　　そのうちtrueが伝わるだろう
　・cancelは変数で一時停止がEventだが、どちらかに統一しとけ
　・entrypointはprivateにしとけ
　・entrypintでrunの例外処理しないとendthreadexが呼ばれない
　・キャストはreinterpret_cast使え
　・サブスレッドの実行を管理するThreadとサブスレッド処理のクラスを
　　どうして同じにするかな。runとcancel_checkはThreadと別クラスに分離した
　　方がよいと思う
　・_beginthreadexとCreateEventのエラーチェックしろ
　・サブスレッドが完了したか調べる関数がほしい
あと、Threadがスコープから抜けるとrunのthisが無効になる設計は嫌いだ。
Threadのデストラクタでjoin(WaitForSingleObject(hthread_))すべきだと思う。
呼び出し側が責任を持って事前にcancelを呼び出し、それを怠ったら
不正メモリアクセスでなく永久waitになった方がマシ

次ページ