Masami HIRAMATSU
hiram****@sdl*****
2002年 7月 9日 (火) 15:45:44 JST
平松＠日立です。 AKIYAMA Nobuyuki wrote: > 秋山＠富士通と申します． > > Masami HIRAMATSU wrote: (snip) > ひとつ教えていただきたいのですが，このような修正を行なおうとした > 背景を教えてください. > 実際，ハンドラ登録のミスなどによりバグを作りこんだ事例が起こった > とか・・・. > 問題点が共有できれば,修正方法の議論もし易いと思います． これはLKSTのコードレビューを行っている際に見つかったものです。 実際に問題となる事例があったわけではありませんが、してほしくない ことを禁止していないのも変だと思いましたので。 >>(2)バッファオーバーライト判定にバグの可能性。 >>(3)バッファ解放時に(ロックを取っていないので)アクセスバイオレーションを >> 起こす可能性がある。 (snip) > ここで言う「ロック」とは,バッファ操作用のロックのことですか？ > イベント取得時にロックしていないため,バッファ削除時のロックが意味を > なさないため,削除されたバッファにイベントを書き込む可能性があると言 > うことですか？ そうです。イベント取得時にロックをかけるとオーバーヘッドが 大きくなってしまうので、ロックをかけずに済ませるために上記の 解決法を提案しています。 >>(2) (snip) > ここで「set_rmodによって」とあるのですが，この機能を知らないの > ですが,どのような機能なのか教えていただけると助かります. set_rmodというのは、イベントバッファから読み出す前に、その プロセス(普通はlkstlogdの読み出しスレッド)がどのCPUのバッファを 読み出すのか、またそのときのフォーマットをPOSIX仕様にするか、 を決めるためのioctlコマンドです。 少し分かりにくいとは思いますが、仕様書(pdf)も参考にしてください。 > また,CPU affinityな機能は,2.4カーネルに入っていましたっけ？ 狙ったCPUにmigrateする機能は、(undocumentedかも知れませんが) 存在します。本来はksoftirqdを実装するためのものですが、タスク 構造体にcpus_allowedというマスキングフラグがあるので、これに 2^nをいれてschedule()を呼び出すと、cpuid = nのCPUで動作する ようになります。 >>(3) (snip) > なぜ二重のチェックが必要なのでしょうか？ > このあたりのからくり説明をしていただけると非常に助かるのですが. shiftイベントは、(1)バッファがいっぱいであり、(2)次に遷移できる バッファが存在する、とイベントハンドラ内部(正確には書き込み用 関数部)で自動的に発生します。(もちろんこの機能を無効にすることも 可能ですが。) そうすると、migrateする前のタスクがcurrentフラグを確認して、次に defunctフラグを立てるまでの間に、何らかのイベントが発生し、 次いでshiftイベントが発生する可能性があります。(非常にまれです) このため、defunctを立てた後に、さらにもう一度確認する必要がある わけです。 #もちろん、migrateしてからdefunctフラグを立てればこのような問題は #無いですが、schedulingに時間がかかりそうなので、このようにして #います。 ##こうしておけば、BHに入れる、という応用も利きそうなので:-) 最後の質問には畑崎さんが答えていますので、 そちらを参照していただけますか。(^^; -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiram****@sdl***** (外線)044-959-0258 (内線)8-69-3346
