K.Maebashi's BBS

>ここで、スレッドを3本起動しており、「タイマ表示」という関数名の関数を >呼び出しているようですが、その「タイマ表示」関数は、引数のqidを順に >変えながら、3回呼び出されているように見えますが……(そして毎回、自ら >returnしている) 　ああ、やっぱりそう見えましたか。実は裏のデバックトレースが重過ぎて 実行が周期内に終わっていないのです。常にオーバフロー状態なんです。 で、デバックトレースOFFにすると、表示自体がデバックモニターの分類３ を使っているので、表示も消えてしまうと言うジレンマが… 　なので、最後にデバックトレースのサンプルを出したのですが、やはり^^; 実際は、VMの実行がトレースのためにめちゃくちゃ遅いのです。プログラムの 途中で処理が変わるどころか、バイトコード１命令の実行の中で２－４回VMが 変わって、VMがそれぞれの担当処理を実行しようとがんばっています。 しかし、デバックトレースは、UDP通信でデバックモニターに送っているので、 その通信をしたタイミング（通信処理のためのスレ一時中断）でスレッド チェンジが起こってしまっています。デバック情報１行送るたびにスレッドが ころころ変わってしまっています。 　まあでも、とてもいいデバック環境でした、ほんの些細なタイミングミスも、 ころころ引っかかるので、もう異常が出まくりでした。つぶすのは大変で したが、つぶし終わった後いろいろ変えてもなんら問題がおきませんでした。 　で、そのまま使ってたデータで文を作ってUPした後、これまずいかなーと 思って、デバックトレースサンプルを追加してみました。 　間違いなく、main＋３スレッド=４スレッド、細切れどころかミジン切れの 状態で動いています。後で、タイミングを長くしたものの出力でもUPします。 今ちょっとノートPCシステム入れ直ししてて、それにかかりっきりで… 手順を簡単に説明すると。下のスレ開始から > sid[0] = スレ開始("タイマ表示",40,6," 40ms"," で6回実行"); １、スレッド初期起動キューが作成される ２、空きVMがキューをGET位して、タイマ表示関数を実行 ３．タイマ表示関数は初期起動なので、システム変数を生成し 　　初期化とパラメーターをセーブして、待機終了　returnする ４、管理部分が、周期起動のスレッドが有るので、そのスレッド向けに 　　時間が来たら、周期起動のキューを作る。 ５．空きVMが周期起動キューを取り出し、その関数を実行する。 ６．タイマ表示関数は周期起動キューで起動されたことを理解して 　　カウンタを＋１して、そのカウンタを表示する。そして待機return ７．また４に戻り周期キューが作成されるー＞４に戻り ８．タイマ表示関数は周期起動キューの中で、回数値とカウンタを 　　比較してカウンタ＞＝回数なら、終了returnして、スレッドが終わる。 　こんな感じで動いています。たぶん説明が抜けていたのは、システムが 周期キューを生成している部分だと思います。 例えば、６回実行のスレは、初期１回とタイマー６回で、合計７回実行 しています。 　スレ１が７回、スレ２が６回、スレ３が５回実行しています。 で、タイマ表示関数は周期に追いついていないので、システムは回数以上 の周期タイマーキューを生成していて、VMが実行しようとしています。 また、ちがうVMが同じスレッドの周期キューを平行して実行しようと してしまいます。もちろんこれは問題が起こるので、そうならないように 作られています。言葉で言うと簡単そうですが、複雑な制御をしています。 　常に重い状態で動いているので、キューが溜まってヘビーな状態で デバックをしていました。 >「タイマ表示」関数がreturnしないまま、別のスレッドに制御を奪われることって >あるんでしょうか? もう、１回のキュー処理で数十回はVMのスレッドチェンジが起こっています。 各スレッド処理は、みじん切りの細切れで並列に動いています。 デバックトレースを止めればそのようなことは無いと思います。 　デバックトレースを止めた時に、どの様なタイミングで切り替わるかは 興味があります。しかしそれを調べるためには、表示は一切使えないんで すねね、なんに表示してもその間に切り替わるから。オンメモリーだけで 高速のトレーサでも作りこまないと、それでも、VMの方が早いかもしれ ない。