100129

FF13続き。M29ジャガーノート。これ倒すのは楽なのだけど五つ星をとるのに苦 労した。冥碑はマハーバラ坑道で遠いし。と、ふと気付いた。モンスの前でセー ブしておいてリトライすればよかった。ネトゲ脳の恐ろしさでリセットしてや り直すという概念を忘れていた...。失敗する度にミッション受け直していた。
ジャガーノートの沸くテージンタワーの周りもいい景色です。

このジャガーノート、弱体なしには無理だった。奇襲は簡単に入る。そこで焦 らずJAM/BLA/JAMできっちり弱体を入れる。これでブレイク中のダメージの入り が格段に違ってくる。わかればなんてことない攻略なのだけど。リトライ6回く らいしたかな...。

ここから眺めるコクーンも良い。次はテージンタワーのミッションの五つ星化だ。

スケジューラアクティベーション続き。どうもTopazの実装が直感に反する実装 なような気がしてならない。並行プログラミングのモデルでは、今で言えばこ の手の並行処理パッケージはpthread一色だけれども、この頃は群雄割拠の時代 だった。UNIX系では最終的にMachのCThreadをベースとしたpthreadが制した。 なのでスケジューラアクティベーションをあらゆる並行性モデルのプリミティ ブとして使えるという利点はほとんどない(UNIX系では)。

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.


 この量を明らかにするために、表1ではユーザ層スレッド、カーネルスレッド、
UNIX風プロセスの例としての実装の性能を示している。これらは全て同じCVAX
プロセッサの上で動かしている。FastThreadsとTopazのカーネルスレッドは
CVAX Firefly上で計測し、Ultrix(DECのUNIX派生物)はCVAXの単一プロセッサの
ワークステーション上で計測した。(これらの実装のそれぞれは良いが最適では
ない。なのでこの測定は例であって、絶対ではない)

 二つのベンチマークは「Null Fork」で、何もしない手続きのスレッド/プロセ
スを生成し、スケジュールし、実行し、完結する時間(スレッドをforkするオー
バーヘッド)を計るものと、「Signal Wait」待ち状態のプロセス/スレッドにシ
グナルを送り、その状態を待つ時間(二つのスレッドを同期させるオーバーヘッ
ド)である。それぞれのベンチマークは単一プロセッサ上で実行し、結果は多数
反復した結果の平均である。比較のために、関数呼び出しはFireflyで7usec、
カーネルトラップは19usecかかる。

表 1 スレッド操作待ち時間(usec)
操作		FastThreads	Topaz threads	Ultrix processes
Null Fork	34		948		11300
Signal-Wait	37		441		1840

表1は、Ultrixのプロセス管理とTopazのスレッド管理の間には一桁の違いがあ
るが、さらにTopazスレッドとFastThreadsの間には桁で違いがあることを示し
ている。Topazスレッドのコードは多くの重要な部分はアセンブラによって書か
れ、高度に最適化されていているにもかかわらずだ。

一般に、システムサービスを実装するところで、柔軟性と性能の間でトレード
オフが生じる[26]。しかしながらユーザ層スレッドにはこのトレードオフがな
い: 性能と柔軟性が同時に向上する。スレッドシステムにおいて柔軟性はとり
わけ重要で、多くの並行プログラミングが存在し、それらはスレッドシステム
による特別な支援が必要かもしれないからだ。カーネルスレッドで、複数の並
行プログラミングモデルの支援をしようとすると、カーネルの変更が必要であ
り、それによって複雑さ、オーバーヘッドが増し、そしてカーネル内に問題が
起きがちである。

2.2 伝統的なカーネルインターフェースの上に構築されたユーザ層スレッドの
統合性の悪さの原因

カーネルスレッドとして提供されるサービスと同等のものをユーザ層スレッド
に実装することは難しいことが残念ながら明らかになった。これはユーザ層で
並行性を管理することに起因するのではなく、現存のシステムのカーネル支援
の不足の結果である。カーネルスレッドはユーザ層のスレッド管理には悪い抽
象化である。二つの関連したカーネルスレッドの性質によって困難さが生じる。

 - カーネルスレッドはユーザ層への通知なしに、ブロックし再開し、横取りさ
   れる。

 - カーネルスレッドはユーザ層のスレッドの状態に関係なくスケジュールされ
   る。

 これらによって、単一プログラムであっても問題を生じる。ユーザ層スレッド
システムは、しばしば多くのカーネルスレッドを「仮想プロセッサ」としてシ
ステムにある物理プロセッサの数だけ作成するだろう: それぞれでユーザ層の
スレッドが走るだろう。ユーザ層のスレッドがブロックI/Oをしたり、ページフォ
ルトをした時、その仮想プロセッサとして供されているカーネルスレッドもブ
ロックする。結果として、I/O待ちの間、物理プロセッサはアドレス空間に失な
われてしまう。なぜなら、他のユーザ層スレッドで走るカーネルスレッドがな
いからだ。そこだけ待機しているプロセッサで他のユーザスレッドを走らせる
カーネルスレッドがないからだ。

これに対するもっともらしい解決は物理プロセッサの数以上のカーネルスレッ
ドを作成することだろう; あるカーネルスレッドのユーザ層スレッドがカーネ
ル内でブロックした時、他のカーネルスレッドがそのプロセッサでユーザ層ス
レッドを走らせることができる。しかしながら、I/O処理が終了したりページフォ
ルトから帰ってきた時に難しさが生じる:プロセッサの数より多くの走行できる
カーネルスレッドが必要になるだろう。それぞれのカーネルスレッドはユーザ
層を走行している最中である。どのカーネルスレッドをプロセッサに割当てる
か決定することにおいて、OSは暗黙的にどのユーザ層スレッドをプロセッサに
割当てるかを選択している。