100211

天井にレールもついて、これで塗装の時に上から釣り下げるのも安心。この仕 様で木工＆塗装再開。まだまだ作りたいものがたくさんあるんだ。

FF13続き。最近のタイマイ狩り。足をB/B/Bで行くか、B/J/Bで行くかどっちが いいのかいろいろ試していたのだけど、B/B/Bなら1ターンでブレイク、B/J/Bだ と2ターンでブレイク。B/J/Bの方が弱体のおかげでその後が多少安定感。この時 ファングはコマンドでファイアの連続。近づくとだめ。
両足ブレイク後にA/H/Bでハイウィンドでそれぞれ潰す時に、たまに削り残す。 一番下のB/H/Bはこの時用。
倒れた後にE/J/EかE/J/Bかの選択は、どっちでもあまり変わらない。
その後B/B/Bでブレイク後最低でも850%までB/B/BでもっていかないとA/A/Aにし た時のチェーンボーナスを稼げない。
これでハイウィンドをかますことなく立ちあがるまでに削りきれる。

ファングは近接攻撃するのでどうしても耐性装備は必要。

ヴァニラは後衛なのでこの程度の耐性で十分。

サッズはいかなるロールでも近接しないので耐性装備省略してる。でも結構ギ リギリ。狩的立位置に使い出がある。亀戦の場合、敵が大きいので全弾必中と いうのもサッズが活きるところ。

トラペゾヘドロン余り過ぎ。あぁランス・オブ・カイン★分解でトラペゾヘド ロン増殖なんてしなければよかった。あんなことしなけば150万Gは余っていた はずだ...。

スケジューラアクティベーション続き。

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.

例えばFastThreadはロックのないプロセッサ毎(現実にはアクティベーション
毎)の、自由に使えるスレッド管理領域の一覧を、遅延時間を低減するために使っ
ている[2]。これらの一覧を操作する時も原子的に行なわれないとならない。

都合の悪い横取りの問題を処理するのに、「予防」と「復旧」の二つのやり方
がある。予防では、カーネルとユーザ層の間でのスケジューリングやロックに
よって、都合の悪い横取りを防ぐ。とりわけ並行処理環境において「予防」に
はいくつかの重大な欠点がある。「予防」はプロセッサの割当ての管理を(少な
くとも一時的に)カーネルからユーザ層に渡す必要があり、アドレス空間の優先
度の意味論に違反する。「予防」はこの先4.3章で述べるきわどい領域に対する
実装と矛盾する。最終的に、「予防」では、ページフォルトがある場合、きわ
どい領域の間、そこで読み書きされるかもしれない全ての仮想ページを、物理
メモリに固定しておく必要がある。これらのページを同定するのは難しいこと
だ。

その代わりに、我々は「復旧」に基づいた解決方を採用した。アップコールが
ユーザ層スレッドシステムに、スレッドが横取りされたかブロックから解除さ
れたことを知らせる時、スレッドシステムは、そのスレッドがきわどい領域を
実行中かどうかを調べる(もちろん、この調査はいかなるロックを取得する前に
行なわれないといけない)。もしきわどい領域を実行中であれば、そのスレッド
はユーザ層によるコンテキストスイッチで一時的に実行を続ける。そしてこの
スレッドがきわどい領域を抜けたら、再びユーザ層のコンテキストスイッチに
よって元のアップコールに制御を戻す。この時点で、そのユーザ層スレッドを
実行待ち行列に戻して安全である。アクティベーションがカーネルの事象を処
理している最中に横取りされた時にも同じ機構を使って、処理を継続する。

この技法はデッドロックの制約がない。ロックを保持しているスレッドの実行
を続けることによって(それは最終的には開放される)、ページフォルトあるい
はプロセッサの横取りがあってもロックを確実に取得できる。さらには、この
技法はユーザ層のスピンロックにも使える。ユーザ層スレッドシステムは横取
りが起きた時には常に通知を受けるので、スピンロックを保持したスレッドを
継続して実行することが可能だからだ。正確さには影響がないが、プロセッサ
の時間は、スピンロックを保持したスレッドがページフォルトを起こすと無駄
にスピン待ちするかもしれない。これに対する解決は、しばらくの間スピンし
た後にはプロセッサを放棄することだ[4]。

4. 実装

3章で述べた設計に基づき、Topazとそのユーザ層スレッドシステムである
FastThreadsに変更を加えることで実装した。TopazはDEC SRC Fireflyマルチプ
ロセッサワークステーションのOSである。Topazのカーネルスレッド管理ルーチ
ンを改造してスケジューラアクティベーションを実装した。以前のTopazではス
レッドをブロック、再開、横取りしていた場所で、アップコールするようにし
て、ユーザ層がこれらに対して作用できるようにした(表2を見よ)。さらに、ア
ドレス空間に明示的にプロセッサを割当てるように改造した。以前はスレッド
のスケジュールはそれが属するアドレス空間に無関係であった。バイナリ互換
性も保持した。現存するTopaz(つまりUNIX)のアプリケーションも以前と同じよ
うに実行できる。

FastThreadsはアップコールを処理し、割込まれたきわどい領域から復帰できる
ようにし、そしてカーネルにプロセッサ割当ての決定に必要な情報を提供する
ように(表3を見よ)改造した。

全部で、FastThreadsには数百行、Topazには1200行ほど追加した。(比較として、
もともとのTOpazのカーネルスレッドの実装は4000行以上である) 新しくTopaz
に追加されたコードの多くは、プロセッサ割当ての方針(以下で述べる)に関す
るコードで、本質的にスケジューラアクティベーションではない。

我々の設計は、アドレス空間にプロセッサを割当てる方針と、プロセッサ上で
スレッドのスケジューリングの選択には中立である。もちろん、試作の実装に
はこれらの方針の組みあわせのいくつかを選ばないといけない。続く章では、
これらについての要約と、性能向上とデバッグに関する考察を述べる。

4.1 プロセッサ割当て方針

我々が選択したプロセッサ割当て方針は、ZahorjanとMcCann[27]の動的方針に
似ている。優先度を考慮し、仕事がある場合にはプロセッサが遊ぶことがない
ことを保証する間、プロセッサは「空間を共有する」方針である。プロセッサ
は最高優先度のアドレス空間の間で等しく分けられる。もしいくつかのアドレ
ス空間がそこで共有されているプロセッサが全ていらなくなれば、これらのプ
ロセッサは、それ以外に均等に分配される。空間共有によってプロセッサの再
割当てを減らすことができる。使用可能なプロセッサの数がそれを必要とする
アドレス空間の数の整数倍でない時だけ、プロセッサは時分割される。

全てのアドレス空間がスケジューラアクティベーションを使わないといけない
わけでなく、カーネルスレッドを使うこともできるように実装した。現存の
Topazアプリケーションを(この先も)実行できるようにするにはカーネルスレッ
ドもサポートしないといけないからだ。この実装では、カーネルスレッドを使
うアドレス空間は、スケジューラアクティベーションを使うアドレス空間と同
じやり方でプロセッサを獲得する。