工作部屋のシロッコファンが剥出しのままだったので、見栄えをよくするため
の部品を作りました。今回はじめてトリマーで円をくり抜いてみた。直径の調
整がちょっと面倒だけれど、それさえ決まれば作業は早いし、仕上りは綺麗だ
し、いいかも。
FF13続き。トラペゾヘドロンがやっとでた。400万G近くたまっていたので、ラ ンス・オブ・カイン★の解体でトラペゾヘドロンx3に。これでライト、ファング、 ヴァニラの武器を最終に。ついにATBスロットが6に...。
さて、大地の指輪を3つ作って、シャオロングイに再挑戦。以前よりは戦えるよ うになったとはいえ、きつい。「ほえる」で虚脱→クエイクで全滅すること 3,4回。やっと倒せた。運よくダークマターは手に入ったものの、難しい...。
まだまだギル稼ぎが必要なのでプラチナインゴット目当てにアダマンタイマイ を狩ることになる。ここまで来ればガチ狩りでもいいかなと思いきや、これも 結構難しい。正直デス狩りでもまず失敗しない。ダッシューズ+ATB15%加速で入っ て召喚中に6回、ここでヘイストが切れるのでENHに入れ直してもらって、倒れ ている間に8回、立ちあがっても2回、計16回くらいのうちに大体殺れる。
ここしばらくはプラチナインゴット狙いに延々とタイマイ狩りかな...。
スケジューラアクティベーション続き。スケジューラアクティベーションはス ケジューラを二つに分割する。片方はCPUの割当てのみ。片方はアドレス空間毎 のスレッドのスケジューリング。どちらの側でもブロックすることがあるため その情報をやりとりする。この境界をカーネル/ユーザで分割するため、実装上 の複雑さがある。まずはカーネルの中だけでこういうインターフェースの分割 をして、さらにそのスケジューラ部分をユーザランドにもっていくという感じ に実装していくと見通しがいいかも。
FF13続き。トラペゾヘドロンがやっとでた。400万G近くたまっていたので、ラ ンス・オブ・カイン★の解体でトラペゾヘドロンx3に。これでライト、ファング、 ヴァニラの武器を最終に。ついにATBスロットが6に...。
さて、大地の指輪を3つ作って、シャオロングイに再挑戦。以前よりは戦えるよ うになったとはいえ、きつい。「ほえる」で虚脱→クエイクで全滅すること 3,4回。やっと倒せた。運よくダークマターは手に入ったものの、難しい...。
まだまだギル稼ぎが必要なのでプラチナインゴット目当てにアダマンタイマイ を狩ることになる。ここまで来ればガチ狩りでもいいかなと思いきや、これも 結構難しい。正直デス狩りでもまず失敗しない。ダッシューズ+ATB15%加速で入っ て召喚中に6回、ここでヘイストが切れるのでENHに入れ直してもらって、倒れ ている間に8回、立ちあがっても2回、計16回くらいのうちに大体殺れる。
ここしばらくはプラチナインゴット狙いに延々とタイマイ狩りかな...。
スケジューラアクティベーション続き。スケジューラアクティベーションはス ケジューラを二つに分割する。片方はCPUの割当てのみ。片方はアドレス空間毎 のスレッドのスケジューリング。どちらの側でもブロックすることがあるため その情報をやりとりする。この境界をカーネル/ユーザで分割するため、実装上 の複雑さがある。まずはカーネルの中だけでこういうインターフェースの分割 をして、さらにそのスケジューラ部分をユーザランドにもっていくという感じ に実装していくと見通しがいいかも。
Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism Thomas E.Anderson, Brian N.Bershad, Edward D.Lazowska and Henry M.Levy University of Washington ACM Transactions on Computersystems, Vol.10, No.1, February 1992,p53-79. 伝統的なシステムでは、プロセッサより多くの走行可能なスレッドがある場合、 それぞれのスレッドが進行することを保証するために、いろいろな種類の時分 割の手法を用いることができた。しかしながら、カーネルスレッドの上でユー ザスレッドが走っている場合、時分割は問題を起こすことになる。例えば、ユー ザ層のスレッドがスピンロックしている間にそのカーネルスレッドは横取りさ れ得る;そのロックを取ろうとするユーサ層スレッドは、ロックを保持している スレッドが再走行するまでスピン待ちするだろう。Zahorjanら[28]はスピンロッ クがある場合の時分割が悪い性能になることを示した。他の例として、ユーザ 層のスレッドを走行しているカーネルスレッドは、他のカーネルスレッド、そ れはユーザ層のスケジューラで待機状態になっているものに、横取りされるこ とがある。あるいは、ユーザ層で高優先度のスレッドを走行しているカーネル スレッドは、ユーザ層で低優先度で走行しているカーネルスレッドに横取りさ れ得る。 まったく同じ問題が、I/Oやページフォルトの起こる並行プログラミングにお いて起こる。システムに一つのジョブしかないのであれば、全てのプロセッサ を使うことができる; 他のジョブが投入された場合、OSは最初のジョブのプロ セッサを横取りして、新しいジョブに割当てるべきだ[23]。カーネルは最初の ジョブのカーネルスレッドのどれかを選ばないといけなく、そのユーザ層スレッ ドは残りのプロセッサで走行することになる。ジョブ内での並行性の変化によっ てもアドレス空間からプロセッサを横取りする必要がでてくる; Zahorjanと McCann[27]は、高性能にするには、並行性の変化に応答するためにアドレス空 間の間で動的にプロセッサを割当てることが重要なことを示した。 カーネルスレッドのスケジューリングをユーザ層に反映するカーネルインター フェースを実装することは可能だが[5]、この情報はユーザ層スレッドと深く関 わる； カーネルとユーザ層の間でこの情報をやりとりすることによって、ユー ザ層スレッドを使うの利点である、性能や柔軟性の多くをだいなしにしてしま う。 結局、カーネルスレッド上に構築されたユーザスレッドの論理的に正しい動き を保証することは難しい。多くのアプリケーション、とりわけアドレス空間を またいだ整合性が必要なものは、全ての走行可能なスレッドは最終的には必ず プロセッサ時間を得れるという前提のもとにデッドロックを回避している。ア プリケーションがカーネルスレッドを直接使用した時は、カーネルの時分割に よってこの前提は保証される。しかし、ユーザ層のスレッドが、固定された数 のカーネルスレッドに多重化された場合、この仮定はもはや保証されない。カー ネルスレッドがそのユーザ層スレッドでブロックされた場合、他の走行可能な ユーザ層スレッドや、使用可能なプロセッサがあったとしても、アプリケーショ ンはその実行コンテキストとしてのカーネルスレッドを失ってしまうからだ。
