08/06/08 13:55:21
>>764
重複I/Oを使うときにのイベント待機に使う。
770:デフォルトの名無しさん
08/06/08 19:17:36
>764
SleepExとかWaitFoｒ～Exで、bAlertable=TRUEの状態で寝てるとき
771:762です
08/06/09 00:32:13
>>763
> ・コンストラクタで生成してるけどサスペンドで作成
→ 論理的に正しく動くのはわかったけど、わかりづらくない？
ハンドル作成したスレッドが(デストラクタあたりで)closeするのが自然だと思うんだが。
> ・bool使ってやってます。全体的にこれらの操作はミューテックスで排他してるんですが、
→ startの多重チェックに同期は要らない。なぜならstartは
一つのスレッド(メイン)からしか呼び出さないのが前提だから
> Thread自身もRunnableインタフェースを継承してます
それはJava APIと同じ設計だけど、APIの設計ミスだと思う。
各クラスの役割は最低限にしようよ。
Runnable: サブスレッドで実行する処理のクラス(主にサブスレッドで使用)
Thread: Runnableのスレッド実行を管理するクラス(メインスレッドから使用)
実行制御でもcancel/suspend/resumeは処理固有なのでRunnable側に実装。
スレッドハンドルはスレッド実行管理の話だからThreadでclose。
> void Thread::join(DWORD timeout)
できれば戻り値をboolにして
DWORD status = ::WaitForSingleObject(?????)
if (status == WAIT_ABANDONED) throw ????;
return status == WAIT_OBJECT_0; // 完了したかどうか
かな。
772:デフォルトの名無しさん
08/06/09 02:04:45
JavaのThreadにケチつけるアホがいるスレはここですか？
773:デフォルトの名無しさん
08/06/09 02:17:36
JavaのThread implements Runnableは失敗だろjk
774:デフォルトの名無しさん
08/06/09 18:16:32
Treadクラスの継承が失敗だろ
775:デフォルトの名無しさん
08/06/09 23:04:19
761です。もう全然うまくいかないので、なんか言ってもらうために
スレッド周辺のプログラムをアップしてみます・・・。include "common.h"は消していいです
お願いします＞＜
URLﾘﾝｸ(ccfa.info)
776:デフォルトの名無しさん
08/06/09 23:06:31
よし、何か言ってやる。
>>775 がんばれ！
777:デフォルトの名無しさん
08/06/10 01:28:22
>>775
○Mutex
・LockでWaitForSingleObjectの戻り値確認しろ。タイムアウトしたら大変なことになるぞ
○Thread
・何でthread_bodyの定義を書く前に変数宣言できるんだ？コンパイル通った？
thread_bodyのスマートポインタでないとマズくね？
・start内に例外発生するとマズい場所が多すぎ。line 60,61,62,63,64,68
・isAliveのロジックが間違ってる。スレッドがSTILL_ACTIVE返したら区別つかない。
WaitForSingleObject(スレッドハンドル) == WAIT_OBJECT_0 で判断しろ
・ThreadProcで(const Thread&)のキャストは要らないでしょ
・マップ操作前後のロックタイミングはこれでいいと思う
・suspend/resumeのロックはこれでいいと思う
・joinでWaitForSingleObjectの戻り値確認して
・isAliveにロックは不要
・クラス設計が変。currentThreadの返したThreadは何だ？
実際のrunと関係ないrunを持つThreadをnewして返すのは絶対変だ
・Runnableとt_threadの使い分けをもう少し整理して
・ヘッダ名見直せ。<cstdio><windows.h><process.h><map><cstdio><sstream>
> tb=thread_pool_for_runnable[target];//既にあるRunnableの時はそれを使う
？ エラー返すべきでは？
あと、ミューテックスのロックはヘルパークラス作れ。
コンストラクタでミューテックスを受け取ってロックし、デストラクタでアンロック。
でないと途中で例外が発生したときにいちいち対処できない。
> もう全然うまくいかないので
何がうまくいかない？ 何となく動きそうだが。
コンパイルエラーとか言ったら殺
778:デフォルトの名無しさん
08/06/10 07:15:40
今携帯なんで、後で詳しく見ますが、うまくいかないというのは
これで画像読み込みをしたときに画像読み込みが出来なかったりするんです
実験中には終了時に不正アクセスみたいのが出たり…
779:デフォルトの名無しさん
08/06/10 14:38:51
777が優しすぎる
俺が男なら惚れてたね
780:デフォルトの名無しさん
08/06/10 14:56:56
俺は男だから惚れた
781:デフォルトの名無しさん
08/06/10 16:38:37
じゃあ掘れるのか
782:デフォルトの名無しさん
08/06/10 19:43:21
惚れたけど掘れない。
783:719
08/06/10 20:22:05
いやぁ、勉強になるなぁ…。
784:デフォルトの名無しさん
08/06/11 07:10:26
質問があります
pthreadでは途中でスレッドをキャンセルする場合
pthread_cancelを遅延キャンセルでコールして、
クリーンナップハンドラでリソースを開放するという方法が考えられますが、
C++では実行環境(gcc,glibc)によって、クリーンナップ内でオブジェクトの
デストラクタが呼ばれなかったり、例外処理が行われないなどといったことがあるみたいですが、
「C++ではこのようにしてpthreadを中段させるべき」といった
定石的手法が確立しているのでしょうか？
できればURIなど情報源などもあれば教えてください。
【ＯＳ】
Linux2.6
【言語】
C++
【実行環境】
RHEL5（pthread）
【その他突起する事項】
「RHEL5の中のライブラリならサポートしてるので気にするな」ってのは無しで
785:デフォルトの名無しさん
08/06/11 07:47:54
外から中断なんかしない。
当たり前すぎて泣けてくる。
786:デフォルトの名無しさん
08/06/11 12:24:11
>>784
安全に中断させる方法なんて存在しない。
だが、スレッドのエントリ関数のreturnを実行して正しく終了させる方法はいくらでもある。
787:デフォルトの名無しさん
08/06/11 13:55:11
> 「C++ではこのようにしてpthreadを中段させるべき」といった
> 定石的手法が確立しているのでしょうか？
中断通知機構は自分で独自に実装。必ずエントリポイントの関数まで
戻るようにする。
異常時に終了するため、終了用の例外クラスを作成。エントリポイントのみ
でcatchし、他はクラスに対し例外中立なコードを書く。
ソースは俺。
788:デフォルトの名無しさん
08/06/11 14:04:26
>>778
joinせずに終了したか、Thread,Runnableのメモリが誤って解放されたのでは
789:デフォルトの名無しさん
08/06/11 20:40:04
スレッド止めてプロセスにする
790:777
08/06/11 21:51:22
>>775
GetLastErrorの戻り値判定ロジックが逆。
細かい間違いは修正したが普通に動いた。元のろだ?のup方法がわからなかったので↓にup
URLﾘﾝｸ(www11.axfc.net)
DLパスは mt
さすがにmy_ptrとかいうのはboost::shared_ptrに置き換えさせてもらった。
791:デフォルトの名無しさん
08/06/11 22:28:58
アクターモデルって奴の
C++とかjavaとかでのサンプルない？
792:デフォルトの名無しさん
08/06/11 22:36:55
761です
>>790
ﾌﾞﾜｯ!なんと言うやさしさ・・・やっと時間が取れたので、777を元に修正してたら、なんという
でも俺はウホじゃないです。すいません
(const Thread&)のキャストですが、こうしたらローカル変数の寿命がどうたらで1個分生成・破棄の
コストが浮くかなあと思って付けたんですが・・・まぁ、確認もせずにつけたので効果はいざ知れず
> currentThreadの返したThreadは何だ？
この関数を実行したスレッドがスレッドプール内に存在すれば、そのスレッドを操作する
Threadオブジェクトを返します。
既存のRunnableの時再利用するのは
Hoge(){
Thread th(this);th.start();
}
~Hoge(){
Thread(this).join();
}
とすることに憧れていたからです・・・。つまり俺がちょっとおかしいのです
793:デフォルトの名無しさん
08/06/11 23:27:08
pthread mutexで
読みスレッドが2人
書きスレッドが2人
といる場合、rwlock使うと読んでる間に
書き込もうとしてもロックされる？
794:デフォルトの名無しさん
08/06/12 00:24:12
pthreadは知らないけど一般のReader-Writer-Lockなら排他制御されなぎまずいんじゃね。
Readerのみの場合に排他されないんだと思う。
Reader vs. Reader → 排他されない
Reader vs. Writer → 排他される
Writer vs. Writer → 排他される
795:デフォルトの名無しさん
08/06/12 00:38:59
Pthreadもそうだったと思う
Man読みゃいいんだけどね
796:デフォルトの名無しさん
08/06/12 01:47:42
スレッドＡがrdlockする
スレッドＢがwrlockしようとする(が、rdlock中なのでブロック)
この状態の時に、スレッドＣがrdlockしようとすると
１.スレッドＣがrdlockを取得(Ａと共存)出来る
２.スレッドＢ(ロック獲得優先権がある)の処理終了までブロックする
一般的にはどうなる？
・一般的に、rwlockと呼ばれるものの動作として決まっている(どっち？)
・pthreadの標準として決まっている(どっち？)
・何も決まってない(実装依存)
797:デフォルトの名無しさん
08/06/12 01:54:39
>>796
URLﾘﾝｸ(opengroup.org)
＞ It is unspecified whether the calling thread acquires the lock
＞ when a writer does not hold the lock and there are writers waiting for the lock.
何も決まってないぽい
798:デフォルトの名無しさん
08/06/12 02:00:50
おー、thx