2010年2月アーカイブ

この前の筑波の帰りに買ってきておいた荒、中、仕上げの砥石を使ってカンナ の刃を砥ぎ直してみた。今迄なんとなく心の赴くままに自己流で研いでいたの をやめ、本の通りにやってみた。
まず裏押し。こんなのやったことがない。これを荒砥石でやってみたところ、 刃がかなり歪んでいた。あまりにも削る量が多くて今回はちょっと妥協。しの ぎ面の砥ぎは自己流でやっていたのとそう変わらないな。最後は仕上げ砥石で フィニッシュ。これはやったことなかった。
そして裏刃も。裏刃は研いだことがなかった。これも思いっきり歪んでいる。
試しに削ってみると、結構気持ちよく削れる。この分なら次の天板は綺麗に仕 上りそう。その前にもう一回裏押しをきっちりやり直したい。定盤で粗い金剛 砂でガリガリやらないとだめかも。

FF13続き。やっとミッション五つ星化に戻ってきた。ターゲットはM62 ラクタ ヴィージャx2。メンバーはファング/ヴァニラ/スノウ。メーガスブレスLv★,イ ンペリアルガードLv★x2を基本に金時計を持たせる以外はさらにウィッチブレ スで魔法耐性アップ。これで魔法耐性は63%/56%/63%に(前回の100121では 49%/43%/43%)。武器は弱くした方が目標タイムの軽減になるのだけど、敢えて 今回は最強武器で。 戦略は

J/E/B
B/H/B
B/J/B
B/B/B
A/H/A
A/A/A

J/E/B,B/H/B,B/J/B,B/B/Bで常に強化弱体をキープしながらチェーンを稼いで削 るだけ。削りの時のために強化は必ず。ここまで耐性装備すると「れんぞくま」 なんてどってことない。
6:46/11:49で五つ星。100121では36:08/14:50だった。武器が強いので目標タイ ムは減っているけれど、不利ではないレベルか?

朝起きてさっそく池(2)を見てみるとカエル鍋状態。井戸水を入れて脱出可能に。 あまり上まで水入れると猫に金魚を食べられてしまう危険があるのだけど。

絶賛交尾中。立ちバックといったところか。池(1)の方にはあまりいない。この 池(2)ができるまではカエルのメッカだったのだけど。

この前筑波の帰りに買ってきた種イモ。トヨシロって聞いたことがないので買っ てきてみたら、これは加工用(ポテトチップスとか)の種類だったようだ。

量が多いのでぞんざいな場所にも植え付け。パーティションをSPFの端材で作っ てみた。2x6材だとうちの手押しカンナにおさまらないので両側耳を切ったその 耳。

キャベツ。ちょっと暖かくなって成長が速くなってきた気がする。

箱作り運動はラスト2個終了。ここまで作り続けても仕上りが悪い。丁寧に作業 してるつもりでも、まだまだ甘いんだな。

16の時に作ったスピーカーを解体廃棄に。中には普通のキャビネットが入って ます。中から白紙のタロットカードが出てきた。そういうのやめて。内側には 本田美奈子と書いてあった。この頃ファンだった。
これは今は亡きCORALの4F-1Bの推奨のサイズになっている。キャビネットは 147x225x175(d)、ダクトは75x25x85(d)

FF13続き。必要数はたまったけれど、確変きたかも...と、シャオロングイ狩り。 出た。

トラペゾがこんなに余っているのがくやしい。

箱作り運動続き。3箱組み立てました。一部、弟のホーミーに作ったカップボー ドや、50系ハイエースの頃のオーバーヘッドコンソールの集成材を使ってるの で色が変。厚みの関係で表面削れなかった。
これを収納する本体の設計に悩んでいる。機能性、デザイン、自分の工作技能、 コスト、作り易さを考えるとまったく結論が出ない状態。焦らずゆっくりしば らく考えよう。習作から入ってもいいな。

おとといからカエルが冬眠から目覚めてコッコッ鳴きだした。今日の暖かい雨 でコッコッコッコッコッコッ春を謳歌している。雨が降っていると敷石の真中 でボケーっとしているので気をつけないといけない(たまに踏み潰してしまう)。 冬眠明けなのでボケぶりもひどくて、軽く頭を2,3回叩いてやっと動き出す始末 だ。池にも水を補充しておかないと。

ここ最近ゆっくり読んでいた論文の著者(Maurice Herlihy)によるこの手の話題 に関する本の和訳が出ていることを知り、購入。原理から実装まで網羅したこ れはまさに読みたかった本。
筑波選手権の受理書が届いていた。とても残念なことに、特別スポーツ走行が 混走でさらに走行が午後からだ...スケジューリングが難しい...。エントリー 台数も明らかに減ってるし仕方ないのかな。
RS125整備。ハイオクだけによく焼けてる気がする。

気持ちポツポツとデトネた跡があるような気もしなくもないけれど、問題ない レベルだ。

昨日買ってきたt3.0ベニヤ板を使ってさっそく箱の組み立て開始。今日は一個。

FF13続き。ついにシャオロングイを1ブレイクで倒すことに成功した。A/J/Aか らA/A/Aにしたのがよかった。削りの時間は短いのでそこで弱体が切れることは ない。

そしてダークマター。これで必要数揃ったかな。

筑波行ってきました。今日もRS125。先週までの極寒が嘘のような陽気。最高だ。 一本目は10:30。S枠も大賑わい。陽気に誘われて調子もいい。6秒前半で周回で きるし(125だが)、RS125のベストラップを更新して6.1。20年前このマシンで初 めて筑波を走った時のタイムは6.8なんだよね。タイヤの性能が今とは格段に違 うのでやっぱり当時の方が乗れてたのかな。あの頃は頭のネジをどれだけ外せ るかで走ってたしな〜。
今回は手が痺れることもなし。リストカール運動が効いたかも。リストカール 運動して気がついたのは手首の可動範囲がおかしくなっていたこと。毎日キー ボードだけ叩いている日々でギプスをはめているような状態になってしまって いたようだ。手首が並行に動かず斜めになってしまうため、アクセルを握り替 えしないといけなくなってしまったのだ。
今回はじめてハイオク100%で走ってみた。大丈夫っぽい。だめでもいい。

ちょうどチェッカー受けたところで排気音がおかしくなった。アルミで作った フランジが砕けてしまったのだ。どうしようもないので、今日は終わり!と、ふ てて、もつ定食べてぼーっとしていた。が、やっぱりどうしても走りたい。
ジャワティーを購入。缶をはさみで切り裂いて内側と外側用のフランジを作成、 ワイヤーで固定して、さらに耐熱テープで固定。とりあえず暖機程度なら大丈 夫そう。

2本目コースイン。なかなか良さげか?と思いきや、3周目で終了。絶好の日和り だっただけに残念。もっと走りたかった...。次はここ鉄で差し込みのフランジ に作り直してスプリングで引くようにしよう。
3/14に開幕戦なのにMCFAJ最終戦からCR85に乗ってないのも怖い。CR85に注力せ ねば。

ホームジョイ本田で、箱作り運動用のt3.0,t4.0のベニヤ板、あと今後の勉強用 に荒、中、仕上げの砥石を購入。砥石は家に山ほどあるのだけど(親父が使って るやつ)、全部表面が思いっきり凹面になっている。まずは一度教科書通りにカ ンナの刃を研いでみたい。ジャガイモの種イモも出ていたので買ってきた。ジャ ガイモは暖地で作ってもおいしくないけれど、収穫を楽しむには安牌。

箱作り運動。この箱を収納する本体のイメージもだんだんできてきて、それに 合わせるために、3の倍数個じゃないサイズの箱を追加して作成。今日は追加の 2個の部材を所定サイズにまで整えたとこまで。これはSPF

FF13続き。1日1シャオロングイ運動。今日はドロップせず。あと一つ! インペ リアルガードを6つ作るのでちょっと必要数が多い。今日は、あともう一息で1 ブレイクで削りきれそうなところまでいった。面倒がらずに、できる限りベス トにオプティマチェンジが大切なんだよね。
無待機同期続き。ここで"universal object"というのが出てくる普遍物体と訳 してみた。これは具体的にはCompare-And-Swapだ(たぶんll/scも等価なんだと 思う)。これがあれば処理数によらず無待機同期な実装ができる。が、処理数が 限定されているなら限られた同意数の基本要素でも普遍になる。2コア限定なら Test-And-Setでも無待機同期を実装できるということか。しかしあまりにも実 装と乖離し過ぎていてなにがなんだか意味不だ。

Wait-Free Synchronization

MAURICE HERLIHY

Digital Equipment Corporation

ACM Transactions on Programming Langages and Systems, vol.11, no.1,
January 1991,p124-149.

図1 不可能さと一般的さの階層
----------------------------------------------------------------------
同意数	物体
----------------------------------------------------------------------
1	レジスタの読み書き
----------------------------------------------------------------------
2	Test-And-Set, Fetch-And-Add, 待ち行列, スタック
----------------------------------------------------------------------
.	.
----------------------------------------------------------------------
2n-2	n-レジスタ割当て
----------------------------------------------------------------------
.	.
----------------------------------------------------------------------
∞	メモリ-メモリ間の移動、交換、拡張待ち行列、Compare-And-Swap,
	Fetch-And-Cons, sticky byte
----------------------------------------------------------------------

これらの不可能さは、どうしても無待機同期は不可能あるいは不適切であると
いうことを示すものではない。この論文の二番目の部分では、どのような物体
の無待機な実装をするのに使える「普遍的な物体」があることを紹介する。一
般さに単純なテストを与え、n処理のシステムにおいて、物体の同意数がnより
大きい、あるいはnと等しいとしても、それが普遍的であることを示す。図1に
おいて、n層のそれぞれの物体は、n処理のシステムにおいては普遍的である。
機械の構成、あるいはプログラミング言語は、それが基本要素として普遍的な
物体を提供する場合においては、任意の無待機同期を十分に支援することがで
きる。

無待機同期続き。ここでconsensus numberを同意数と訳した。この数はこの論 文で定義された数で、あるオブジェクトが同意数Nであるということは、少くと もN処理での無待機実装をすることができるという定義。
ここでの処理は、物理的な並列処理数。1CPUであればいくらスレッドがあった としても、処理数は1。この場合、それらスレッドの処理はスレッドの切り替え が割り込みを起因とするので(任意に切り替えもできるけれど、それは明らかに 考慮する必要がない)それを制限するだけでいい。これが二つになると両方の CPUの割り込みを禁止したとしても、禁止した時点で走行しているスレッドが、 きわどい領域にやってくる可能性があるので、共有メモリの読み書きの方法で は無理。ここでTest-And-Set命令が出てくるのだけど、実はこの命令でも同意 数2である。

The Many Faces of Consensus in Distributed Systems
John Turek, Dennis Shasha
IEEE Computer 1992

この論文では

非同期共有メモリで失敗に対して停止する傾向のシステムがあったとしよう。
Herlihyは同期基本要素の同意数を定義した。同意数nの基本要素は任意のn-1の
プロセッサが停止したとしても、同意を達成することができる。定義により、
nではない、同意数n-1の基本要素はは同意数nの基本要素を構成することができ
ない(そうでなければその基本要素は同意数nだろう)。逆に、同意数nの基本要
素はn-1の基本要素を構成できる。

と紹介している。ここで「同意」というのはオブジェクトを共有する処理に おいて、その処理それぞれがオブジェクトの状態を同一に認識できることだ。 この論文の導入は面白い

ボブとアリスは多くのことで共通することを気づいた。例えば、彼らは電
話よりE-mailを好んだ。寒い冬の日、アリスは10:00にボブにメールした。
「正午にLa Trysteの前で会おうよ」

この二人の間のE-mailの接続は、その通信を落としてしまうことで知られ
ていた。しかし今日は幸運にもアリスのメールはボブのワークステーションに
10:20に到着した。ボブは予定表を見ると、昼食は自由だ。そして彼は
承諾のメールを送った。

アリスはその承諾を10:45分に受けとった。そして出かける準備をし、ふ
と彼女は思った: 「もしボブが、私が彼の承諾のメールを受けとったこと
を知らなかったら、彼は私が待っていないと思うかもしれない。彼の承諾
の承諾をした方がいい」

 And so it goes. We can show that, ultimately. ボブとアリスのど
ちらも、少なくともどちらかの一人が、他方を待つために寒い中待ち続け
ることがないことを、完全に示せる。

これを例にして話が進む。

 + 信頼できる通信手段の教え。電話はこの問題を解決する。
アリス: 昼に会おうよ
ボブ: OK。じゃ、後で

E-mailが即時性も到達保証もないというのは一般にはもう伝わらないかも..。 今でもないのだけれど。

Wait-Free Synchronization

MAURICE HERLIHY

Digital Equipment Corporation

ACM Transactions on Programming Langages and Systems, vol.11, no.1,
January 1991,p124-149.

二つの並行物体XとYがあった時、YによるXの無待機実装は存在するか?

無待機処理が存在することを示すのは明解だ: それを表わせばいい。最近の文
献の多くはこの手法である。例は、不可分でない「安全」なレジスタから「不
可分」なレジスタ[18]、単純な不可分なレジスタから複雑な不可分なレジスタ
[4,5,16,23,25,26,29,31]、ネットワークの結合から、リードモディファイライ
トの操作[11,15]、単純な物体から、待ち行列や集合のような型付けされた物体
[14,19,20]。

そのような実装が「ない」ことを示すのは少々明解ではない。この論文の最初
では、「YによるXの無待機な実装はない」という形式を得る、単純で新しい技
法を提案する。我々はある層の物体はそれより上の階層のどの物体も実装でき
ないというような物体の階層を得た(図1を見よ)。基本的な考えは以下のようで
ある: それぞれの物体はそれに関連づけられる「合意数」を持ち、これはその
物体が単純な合意問題を解決できる最大の処理数である。nあるいはそれ以上の
並行処理があるシステムにおいて、nよりも小さい合意数の物体から、合意数n
の無待機な物体を実装することは不可能であることを紹介する。

FF13続き。ダークマター運動。あともうちょっと。シャオロングイはやっぱり 足を上げたらすぐD/D/Dにして受けた方が効率がいい。弱体も常にフルに入れて おくこと。ダルしか入れるのがない状態で。

箱作り運動続き。余剰材の杉板から電子部品入れスタイルのを五箱。これだけ 仕口が多いと、丸一日がんばって作業してやっと。そしてこれは見た目の通り に組み立てが面倒。これで底板用のベニヤ板の在庫も切れた。

箱作り運動続き。6個作りました。

今迄に作った箱を積み重ねるとこんなに。しかしまだまだ足りない。

FF13続き。一日一ダークマター運動。またやっと一個でた。現在四個。

無待機同期続き。

Wait-Free Synchronization

MAURICE HERLIHY

Digital Equipment Corporation

ACM Transactions on Programming Langages and Systems, vol.11, no.1,
January 1991,p124-149.


1. 導入

「並行物体」は並行処理によって共有されるデータ構造である。並行システム
において、並行物体を実装するアルゴリズムは多くの重要な問題の中心に位置
する。そのような物体を実装する伝統的な手法はきわどい領域を使うことに集
中していた: たった一つだけの処理が、その物体の操作をすることが許される。
それでも、きわどい領域は非同期、耐障害システムに適用するには貧弱である:も
しきわどい領域の中で欠陥のある処理が停止したり遅延した場合、欠陥のない
処理も進行できなくなってしまうだろう。無障害システムであっても、スケー
ジュール時間を使い尽したり、スワップアウトされるたり、ページフォルトや
キャッシュ落ちの結果として、予期しない遅延に遭遇する可能性がある。同様
の問題はいくつかのプロセッサは他のより速かったり、メモリの場所によって
はアクセス時間が遅いような、不均一なアーキテクチャにおいても起こる。

並行データ物体の無待機な実装はどの処理も他の処理の実行速度にかかわらず、
有限の数の処理でどのような操作も完了できることを保証する。無待機条件に
よって耐障害となる: どの処理も他の処理の失敗を検出できないこと、あるい
は、その処理の不定の速度の変化による、処理の完了から妨害されない。
無待機同期の基本の問題は以下に示すように表現される。

二つの並行物体XとYがあった時、YによるXの無待機実装は存在するか?

無待機処理が存在することを示すのは明解だ: それを表わせばいい。最近の文
献の多くはこの手法である。

箱作り運動続き。廃材端材はほぼ処理して、次は使われずに余っている材料。 かつての物置小屋建築の残り材とか。今回はこの杉材。

荒木取りして製材までしました。

FF13続き。一日一ダークマター運動...が、頓挫。どうもこれも確変だったよう だ。落とさなくなってからは5,6体狩っても音沙汰なし...。 ここでシャオロングイ狩りをまとめておこう。

ファング/ヴァニラ/サッズ

ランス・オブ・カインLV.★(ブレードランス)
カイザーナックルLV.★
大地の指輪LV.★
月虹のアンクレットLV.★
源氏の小手LV.1

ニルヴァーナLV.★(ベラドンナワンド)
ベストチョイスLV.★
大地の指輪LV.★
月虹のアンクレットLV.★
インペリアルガードLV.★

トータルエクリプスLV.★(アンタレス)
カイザーナックルLV.★
大地の指輪LV.★
月虹のアンクレットLV.★
源氏の小手LV.1 (←これいらないかも。)

D/D/D
B/J/E
J/H/E
B/H/B
A/J/A
A/H/A

開幕D/D/Dでクエイク受け。B/J/Eでコマンドでファイア連打。全員黄色で J/H/Eダル連発。ダルが入ったら攻撃しないで形勢回復。そのあたりでアルテマ がきてD/D/D。B/H/Bで一気にブレイク。A/J/A,A/H/Aで削る。どうにもならなさ そうな時は迷わずTPでフルケア。アルテマ、ほえる、クエイクはどんな時でも D/D/Dで受けること。
無待機同期続き。(Wait-Free Synchronizationには無待機同期の訳を採用しました)
読み初めというのは右も左もわからなくて厳しい。とりあえずちょっとでも進みます。

Wait-Free Synchronization

MAURICE HERLIHY

Digital Equipment Corporation

ACM Transactions on Programming Langages and Systems, vol.11, no.1,
January 1991,p124-149.

無待機同期

無待機に並行データ物体を実装することというのは、どの処理も他の処理の実
行速度にかかわらず、有限の数の処理でどのような操作も完了できることを保
証することだ。あるデータ物体を他のそれから無待機に実装する問題は、最近
の多くの並行アルゴリズム、並行データ構造、マルチプロセッサ機械において、
中心に位置する。最初に我々は、単純で一般的な技法を紹介する。それは一般
的な手順に還元することに基づいて、「YによってXの無待機な実装は存在しな
い」という形式の証明を与える。我々はある層の物体は、それより下の層の物
体によって無待機を実装できないという階層化を引き出した。とりわけレジス
タの不可分な読み書き操作、これは最近多くの注意が集まっているが、これは
最下層に位置する。これらは多くの単純で良く知られたデータ型の無待機の実
装には使えない。さらに、test&setとfecth&addのような昔からある同期基本要
素、これは「読み書き」よりは強力だが、標準的な通信の基本要素としては、
これにも弱点がある。二番目に、それでもあらゆる連続した物体の無待機な実
装をすることができる、単純で一般的な物体があることを示す。

整理箱組み立て。またいろいろと積め込み。部屋にいろいろあるものを見積っ てみたところ、この分だと延々と箱を作っていかないといけない。

FF13続き。一日一ダークマター運動。TPでフルケア使ってしまえば安牌なのだ けど、その後のTP稼ぎの時間を考えると微妙だ。時折り、おかしーだろ?ってく らいの攻撃の連続がある。一日一回なら今のところ初回で100%ドロップ。

TP稼ぎは効率からいうと犬xベヒなのだけど、久々にスーリア湖からオルバ郷ま で散策しながらTP稼ぎ。最強武器Lv★だとやっぱり星判定きついね...。このオ ルバ郷の景色、これは雪ではなくクリスタル。しかしこれを見ると滑りたくな る。シャクナゲの北斜面は最高だったな〜。登るのは大変だったけど。

端材処理運動。これも整理箱に。組み立てキットの状態まで。時間に余裕がな くてパッパか作業していたら、寸法間違えてたり、精度が悪かったりで惨々な 出来。時間がなくともそこでゆっくりやらないと。

次はこれ読みます。

Wait-Free Synchronization

MAURICE HERLIHY

Digital Equipment Corporation

ACM Transactions on Programming Langages and Systems, vol.11, no.1,
January 1991,p124-149.

ざっと字面だけ眺めてみたところ、ちょっと無理目かも..。

 r = 1 ∨ (ヨ!P)a[P] = 1, r = 0.

うわわ。こういうの絶望的に苦手なんだよ。基本挫折の方向で。

FF13続き。一日一ダークマター運動。シャオロングイ狩りの勘がだんだんつか めてきた。ような気がする。

端材処理運動。桧と一枚だけ杉。製材だけしておきました。木材に限らずそろ そろもう一度、大廃棄運動しないとだめかな。このままではゴミに埋もれてし まう。

スケジューラアクティベーション続き。やっと読み終わった...。今日読んだと ころでは他の二層スケジューリングのOSとの対比をしている。ちょっとコメント。
きわどい領域に対する処理への著者らの対処は設計ではなく力づくな実装だ。 これを元に優位性を主張はないかと思う。I/O完了後の通知にしても、スケジュー ラアクティベーションの場合、ユーザ層のスレッドの優先度にカーネルは一切 関知しないため、横取りしたプロセッサが実はユーザ層スレッドシステムでは 高優先度だったということがあり得る。なのでその場合横取りのし直しをカー ネルに頼まないといけないため、余計なカーネル/ユーザのやり取りが生じる。
著者らはCPUがTest-And-Set命令しか実装していなくても大丈夫なようにこう実 装したけれど、スケジューラアクティベーションを実装する規模のマルチプロ セッサのターゲットであれば、Load-Link/Store-Conditionalあるいは Compare-And-Swap命令はあるだろう。wait-free同期にしてしまう方がいいかも。
他の2実装にある共有メモリは、いい解決になるかもしれない。ユーザ層でのス レッド優先度をいちいちシステムコールで伝えていたら大変なことだけど、こ れを共有メモリに置いておいて、カーネルが横取りする時にこれをヒントにす れば余計なシステム/アップコールが防げる。(これはスケジューラアクティベー ションのポリシーには反するけれど)
この共有メモリは4BSDのVAXのu領域のようにすれば、シグナル処理を含めた アップコールの仕組みを素直に実装できそう。
I/O完了後、カーネルの後処理を終えてユーザに戻るとこまで実行してそのコン テキストをアクティベーションに載せてユーザ層に渡すところは(これはかなり 面倒だ)Using Continuation to Implement Thread Management and Communication in Operating Systemにあったような、継続を使って機種非依存 な形にもっていくといいだろう。
まず大切なのは旧来のシグナル機構のままきれいに実装することかな。Machの 場合、タスク間のポートによる通信になるわけだけど、ここまでやるとオーバ ヘッドがきつい。旧来の実装は捨て難い。

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.

6 関連する考え

Psyche[20]とSymunix[9]という二つのシステムはカーネル支援を改良すること
でユーザ層のスレッドを適切に統合するという我々の目標ととても関連がある。
両方ともNUMAマルチプロセッサのサポートを最初の目標としていた。Simunixは
高性能な並列UNIX実装として、Psycheは新しいOSとして。

PsycheとSymunixは1,2章で述べたように「仮想プロセッサ」を提供し、ユーザ
層にいくつかのカーネル事象を通知するソフトウェア割込みを定義することで、
これらの仮想プロセッサを補強する。(ソフトウェア割込みは同一プロセッサ上
の全ての割込みは同じスタックを使うということ(なので再入可能ではない)以
外はアップコールのようなものである。) Psycheはさらに、いろいろな種類の
ユーザ定義のスレッドが、異るアドレス空間でそのコードとデータを共有しな
がら、同期できるような、複数モデルの並行プログラムを念頭に入れて調査を
している。

Psyche、Symunixと我々の研究は似た目標を共有しているが、それに対する手段
はいくつかの重要な点で異なる。我々のやり方と違い、PsycheもSymunixもI/O、
ページフォルト、並行プログラムに対するカーネルスレッドの正確な機能を提
供していない。さらにユーザ層スレッドの操作の性能は妥協したものになる。
この理由については2章でいくつか検討した。これらのシステムはアドレス空間
に影響を与えるカーネル事象の全てではなく、いくつかをユーザ層に通知する。
例えば、PsycheもSymunixも横取りされた仮想プロセッサが再開したことをユー
ザ層に通知しない。結果として、ユーザ層スレッドシステムは、いくつのプロ
セッサを持っているのか、どのユーザスレッドがこれらのプロセッサ上で走っ
ているのかを知ることができない。

PsycheとSymunixの両方ともカーネルとそれぞれのアプリケーションの間に書き
込み可能な共有メモリを提供しているが、両者ともカーネルがプロセッサ再割
当てが必要なことをユーザ層が通知する効果的な機構がない。それぞれのアプ
リケーションが必要なプロセッサの数はその共有メモリに書くことができるが、
より多くのプロセッサを必要とするアプリケーションが、他のアプリケーショ
ンでアイドル中のプロセッサがあることを知るいい方法がない。

PsycheとSymunixのアプリケーションは不適切な時に(例えばスピンロックを保
持している時など)横取りが起こるのを防ぐために同期状態をカーネルと共有す
る。Symunixではカーネルと共有する変数をアプリケーションがセットしクリア
することで、きわどい領域の中にいることを示す。Psycheではアプリケーショ
ンがきわどい領域に入る前に差し迫った横取りを調べる。これらのビットをセッ
トしたりクリアしたり調べることによってロックの遅延が大きくなり、これは
高性能なユーザ層スレッド管理をする時のオーバーヘッドの大きな原因となる
[2]。対照的に、我々のシステムでは、横取りが実際に起きていなければロック
遅延への影響がない。さらに、これら二つのシステムではプロセッサを横取り
したいということを、実際に横取りをする「前に」アプリケーションに通知す
る。この通知を元に、アプリケーションはスレッド「安全」な状態を選ぶこと
ができ、そして自発的にプロセッサを放棄する。この機構は高優先度のスレッ
ドは常に低優先度のスレッドの代わりに実行されるという束縛を破る。

Guptaらは[9a]物理プロセッサと走行するユーザ層スレッドの実行コンテキスト
の1:1対応を維持するという目的を、我々と同じくしている。プロセッサの数よ
りも多くのコンテキストがある状態で、I/Oが完了あるいは横取りをする場合、
Guptaらのカーネルはアプリケーションを安全に中断できるところまで時分割し
て実行させる。我々のカーネルでは、コンテキストの数を一定のまま、時分割
をせずに、アプリケーションにその事象を通知することができる。

いくつかのシステムでは非同期カーネルI/Oをマルチプロセッサ上でのユーザ層
スレッドのいくつかの問題を解決するのに使っている[9,25]。実際、我々のシ
ステムは非同期I/Oのような雰囲気がある。I/O要求ができると、プロセッサは
アプリケーションに戻り、そしてその後でI/Oが完了するとアプリケーションは
通知される。しかし、われわれのシステムと伝統的な非同期I/Oとの間には二つ
の大きな違いがある。一つは、一番重要なことだが、スケジューラアクティベー
ションはプロセッサの横取り、I/O、ページフォルトの問題に対して一つの一様
な機構を提供する。非同期I/Oに較べて、全てのカーネルとのやりとりは、一つ
のスケジューラアクティベーションという見地から同じになるということによっ
て、我々の手法は概念的な単純さを引きだしている。カーネル内でブロックし
たスケジューラアクティベーションは待っていた事象が起こると新しいスケ
ジューラアクティベーションに取り換えられる。二つ目に、非同期I/Oではアプ
リケーションとカーネルの両方に大きな変更が必要となるかもしれないが、我々
のやり方では、ユーザ層スレッドシステムとカーネルの構造を大きく変更せず
に済む。

最後に、我々のこの仕組みの一部は、最初期のマルチプロセッサOSの一つであ
るHydra[26]に関連があり、Hydraではスケジュール方針はカーネルの外に出て
いた。しかしながらHydraは、この分離によって性能が悪く、というのはその方
針の決定にカーネルとスケジュールサーバとの通信が必要だったからであり、
その後コンテキストスイッチの実装はカーネル内になった。我々のシステムで
はアプリケーションはスレッドをプロセッサにスケジュールする方針を自分で
設定することができ、そしてこれはカーネルにトラップすることなく実装でき
る。我々のシステムでは長時間のプロセッサ割当ての決定は、カーネルの責任
であるが、Hydraでは、これは別々のアプリケーション層のサーバに任せるよう
になっていた。

7 要約

並行性をユーザ層で管理することが高性能並列計算に重要である。しかし、多
くのOSで提供されてきたカーネルスレッドあるいはプロセスでは貧弱な抽象で
ある。我々は、カーネルスレッド(頻繁ではないが、カーネルの介入がある場合
に正しい振舞いをする)の役割りと、ユーザスレッド(ほとんどの場合のスレッ
ド操作は全てユーザ層だけで実装できる)の性能を組合せたカーネルインター
フェースとユーザ層スレッドパッケージの設計と実装、そしてその性能につい
て述べた。我々の手法は、アプリケーションそれぞれのアドレス空間に仮想プ
ロセッサを与えるということを基本にし、アプリケーションはいくつのプロセッ
サがあるかということを正確に把握し、これらのプロセッサ上でどのスレッド
が走行しているかということも正確に把握する。カーネルとそれぞれのアプリ
ケーションのアドレスの間でその責任が分離される。

- プロセッサ割当て(アドレス空間へのプロセッサの配分)はカーネルによって
  なされる。

- スレッドスケジュール(アドレス空間のスレッドをプロセッサへの配分)はそ
  れぞれのアドレス空間でなされる。

- カーネルはアドレス空間に影響を与える全ての事象をアドレス空間のスレッ
  ドスケジューラに通知する。

- アドレス空間は、カーネルのプロセッサ割当て方針に影響を与えるユーザ層
  の事象のいくつかをカーネルに通知する。

これらの考えを実装するのに使ったカーネル機構をスケジューラアクティベー
ションと呼んだ。スケジューラアクティベーションはカーネル事象にあたって
その制御をカーネルからアドレス空間に誘導する実行コンテキストである。ア
ドレス空間のスレッドスケジューラはこのコンテキストで事象を処理したり、
ユーザ層スレッドのデータ構造を変更したり、ユーザ層スレッドを実行したり、
カーネルに要求を送るのに使う。我々の試作ではスレッドをユーザ層での並行
性の抽象化モデルとして実装したが、スケジューラアクティベーションは特定
のモデルに特定されない。スケジューラアクティベーションでは、カーネルは
ユーザ層のデータ構造に一切よらないので、いかなるユーザ層の並行性モデル
でもサポートすることができる。

謝辞

Andrew Black, Mike Burrows, Jan Edler, Mike Jones, Butler Lampson, Tom
LeBlanc, Kai Li, Brian Marsh, Sape Mullender, Dave Redell, Michael
Scott, Garret Swart, John Zahorjanの有用な意見に感謝する。そして
Fireflyのソフトウェアとハードウェアを提供してくれたDEC System Research
Centerに感謝する。

FF13続き。シャオロングイ狩りに戻りました。久々の一発目はかなり確実にダー クマターを落とす気がする。自分の日記を見て、その通りにプレイしたにも関 わらず、一匹倒すのに3回死んだ。当時より武器は強くなっているのに。シャオ ロングイの場合、敵の攻撃に合わせて確実にD/D/D入れないといけないので(タ イマイならゲージだけ見てオプティマ切り替えるだけ)その攻撃パターンのリズ ムに体が慣れないとだめ。先長いな〜〜。

スケジューラアクティベーション続き。一番最初に抱いたモヤモヤ感というの はカーネルはプロセッサをアドレス空間に分配するという概念だったのだ。時 分割ではなく空間分割。とはいえ..片手で数えれる程度のプロセッサ数であれ ば最終的には空間分割を時分割にせざるを得ない。そうなると横取りのための 頻繁なアップコールによってさらに性能が悪化してしまう。この論文はもっと 大くのプロセッサを想定していた。

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.

5.3 アプリケーションの性能

我々のシステムがアプリケーションに寄与する性能を例証するため、同じ並列
プログラムを、Topazのカーネルスレッド、Topazのカーネルスレッドの上に構
築された元のFastThreads、スケジューラアクティベーションの上で走るように
改造されたFastThreadsを使って測定した。測定したアプリケーションは、
O(NlogN)解のN体問題[3]である。アルゴリズムは、空間のそれぞれの部分の重
心の木表現にし、木を辿ってそれぞれについての力を計算する。離れた質量の
集合による力はその集合の重心からの力で近似される。

プロセッサ速度と使用可能なメモリ量の相対比によって、このアプリケーショ
ンは計算限界にもI/O限界にもなり得る。このアプリケーションのメモリ管理の
部分を、アプリケーションのデータのバッファキャッシュになるように改造し
た。こうすることで、アプリケーションで使うメモリの量を制御することがで
きる。問題を解くのに十分に小さいメモリサイズは、バッファキャッシュが
Fireflyの物理メモリに合うように選ばれる。一層の単純化として、スレッドが
そのキャッシュにミスしたら、カーネルの中で単純に50msecブロックすること
とした。キャッシュミスは普通ディスク操作をするだろう。(この測定は定性的
にディスク操作を考慮した場合と同じになる; Fireflyの浮動小数点性能と物理
メモリ量は現在のシステムに較べて一桁悪いので、あくまで例証だけというこ
とを意図している)

最初に、アプリケーションがカーネルサービスをほとんど使わない場合の説明
する。我々のシステムはTopazスレッドを使った場合に較べて、元の
FastThreadsと同程度にずっと速い。図2のでは、他のアプリケーションはなく、
ほとんどI/Oがなく、十分なメモリがある状態での、プロセッサ数の増加に対す
るアプリケーションの速度の向上をグラフにした。(速度の向上は、このアルゴ
リズムを単一処理した(並列処理をせずに)実装に対する比較である)

 1プロセッサでは3つのシステムとも単一処理実装より悪い。これは並行処理し
た時のスレッドの作成と同期のオーバーヘッドのためである。このオーバーヘッ
ドは他のユーザ層スレッドシステムよりも大きい。

プロセッサ数が増加するにつれて、Topazカーネルスレッドの性能は最初は良く
なるものの、その後は伸びない。Topazにおいて、スレッドはきわどい領域のア
プリケーションのロックの獲得/開放はカーネルを必要としないので、ロックに
対する競合はない。しかし、ビジーロックを獲得しようとする時には、スレッ
ドはカーネル内でブロックし、そのロックが開放される時だけ再スケジュール
される。このようにして、Topazのロックのオーバーヘッドは競合が起きるとと
ても大きくなる。よい性能を出した、ユーザ層スレッドはどちらも、アプリケー
ションとして十分な並行性を見せている。カーネルスレッドのオーバーヘッド
が性能向上の妨害となっている。

カーネルスレッドを使った場合、そのきわどい領域がボトルネックにならない
ように、あるいはロックが獲得できない時にカーネルに入る前にちょっとの間
ユーザ層でスピンする[12]ように再構成することでアプリケーションの性能を
向上するようにできたかもしれない。これらの最適化はユーザ層スレッドの上
でのアプリケーションでは重要ではない。

元のFastThreadsと我々のシステムとでは、4,5プロセッッサのあたりで性能が
異なる。このテスト中には他のアプリケーションは走行していないが、Topaz
OSはいくつかのデーモンが周期的に起床し、ちょっとだけ走行し、また寝る。
我々のシステムでは明示的にプロセッサをアドレス空間に割当てるので、これ
らのデーモンは、まったくアイドル中のプロセッサがない時にだけ横取りをす
る。これは元々のTopazのスケジューラでは違う。そのスケジューラは元の
FastThreadsの仮想プロセッサとして使われるカーネルスレッドを制御する。ア
プリケーションがその機械の全てのプロセッサを使おうとした場合(この場合、
6プロセッサ)、両方のユーザ層スレッドシステムの横取りの数は同じである。
(元のFastThreadsにとってその横取りの影響は少ない。その所用時間は小さい
からだ)

次に、アプリケーションがI/Oによってカーネルの介入を必要とする場合を見る。
我々のシステムは元のFirstThreads、Topazスレッドよりも良い性能である。図
3のグラフは使用可能メモリを変化させた場合にアプリケーションを6プロセッ
サで実行した時の所用時間である。3つのシステムで、最初のうちはゆっくりと
性能が下がっていく。そしてアプリケーションのワーキングセットがメモリに
入らなくなると急激に悪くなる。しかしながら、元のFastThreadsの性能は他の
二つに較べてさらに急激に悪くなる。これはユーザ層スレッドがカーネル内で
ブロックすると、その仮想プロセッサとしてのカーネルスレッドもブロックし、
そのためI/Oの間そのプロセッサをアプリケーションは使用できないからである。
我々のシステムとTopazスレッドの悪化率は同じである。これはI/Oの間に有効
にプロセッサを並行処理に利用できるからである。図2にあるように、それでも
我々のシステムでのアプリケーションの性能がTopazスレッドよりもいいのは、
ほとんどのスレッド操作がカーネルの介入なしに実行できるからである。

最後に、図3はアプリケーションによって引き起こされるカーネル事象による性
能への影響を示したが、並行処理が引き起こすシステムによるカーネル事象に
起因するものにも、我々のシステムは、他の二つ(元のFastThreadsとTopazスレッ
ド)よりも良い性能である。これを試験するために、二つのN体問題のプログラ
ムを6プロセッサのFirefly上で同時に実行し、その平均時間を測定した。表5に
はそれぞれのスレッドシステムでの速度向上を一覧にした。3倍の速度向上が限
界である。

----------------------------------------------------------------------
表5. N体問題 並列処理=2, 6プロセッサ 全てのメモリが使える状態

Topaz	Original	New
threads FastThreads	FastThreads
1.29	1.26		2.45
----------------------------------------------------------------------

我々のシステムは並行処理環境でも良い性能ことを表5は示している。3プロセッ
サで単一処理のプログラムを動かした時では5%以内の向上である。

この低下はバスの競合と、デーモンに周期的にプロセッサを明け渡す必要があ
るためだと思う。対照的に、異なる理由で並行処理環境での性能は元の
FastThreads、Topazスレッドともにもっと悪い。

元のFastThreadsをアプリケーションが使用した場合、OSは仮想プロセッサとし
て使われるカーネルスレッドを時分割する。これによってロックを保持したス
レッドがスケジューリングを外されている間、そのロックの開放を待っている
スレッドの物理プロセッサはアイドル状態となってしまう。Topazスレッドのス
レッドが我々のシステムより悪いのは、一般的なスレッド操作のコストが高い
からである。さらに、Topazは明示的なプロセッサの割当てをしないので、ある
アドレス空間は他のアドレス空間よりも、より大くのカーネルスレッドをスケ
ジュールされるかもしれない。図2では、3つ以上のプロセッサがアプリケーショ
ンに割当てられた時に、Topazスレッドは性能が伸びないことを示している。

Fireflyは概念を試作するにはとてもよい環境ではあるが、プロセッサの数が限
られているので、非常に並行度の高いアプリケーションや、並行実行環境での
並行プログラムの実行という実験には理想的ではない。このため、我々はスケ
ジューラアクティベーションをMachとそのCThreadsに実装している。さらに
Amber[6]というマルチプロセッサネットワーク用のプログラミングシステムを
このFireflyの上に実装している。

今日は廃材処理運動。これは襖の枠で椹。これで整理箱を作ります。もともと 建具なので暴れはないし製材は楽。自動カンナに入れるだけ。

廃材の場合、まず製材したところで、そこからとれる材料に応じた設計になる のでちょっとパズル的なおもしろさがある。

最近見つけたテクとして、巨大サシガネを使ってスライドテーブルの直角を出 すとよい。

組手も全てテーブルソーで。このあたりの作業がまだまだ精度が悪い。椹は非 常に加工がし易い。

底板は新品のt3.0のベニヤから。サイズが微妙で異様に歩留りが悪い...。次は この微妙なサイズで余ってしまったベニヤを使うように作るか。

最近は2時間くらいでクランプは外してしまいます。年末からあれやこれや木工 作業環境向上をやってきて、実際かなり気持ちよく作業が進めれるようになっ た。その時必要な工具だけ出してきて工作、工具しまって掃除。のパターンが やりやすくなったので、クリーンで広い場所を使って工作できるようになった。

いろいろつめてみた。去年この手の整理箱を作りはじめた時は、これを入れる 棚ができるのは来年と言っていたけれど、この分だとさらに来年かな。

FF13続き。パラメキアにて。いい雲だ。セーブデータからの1.5周目もなかなか よい。ホプライ場面を見ようとパルムポルムから初めてみたら、もう一つ前の セーブデータだった。なんとなくやってみると、もう既に話を忘れてきていて ちょっと新鮮。パラメキアまでやってしまった。ホプライもいいけど話として はサッズのヴァニラのところがやはりよい。ヴァニラによる語り部も一度クリ アしてからだと一層重みがある。
手持ちのプラチナインゴットやら素材を換金したら370万Gもあったのでとりあ えずタイマイ狩りは終了。ダークマター目当てにシャオロングイに戻るか...

ダークマター、ゲット。
↓
耐性装備を完全に整える。
↓
ミッション五つ星化

が、これからの予定。

今日は筑波に行こうと思っていたのだけど、あまりの寒さに断念。4月並みに 暖かかった日が今日ならよかったのに。
また机を作ることにしました。いつも通りの仕様。2x6 2.4m二本、2x4 2.4m3本 から荒木取り。天板用の2x6材は余分にもう一本使って、6枚の中からいいとこ 4本取りに。店で買う時に一枚一枚吟味しても、いざ使おうとするとひどいのが まじってる。ここずっと端材処理活動に励んでいたので新品の材料使うのは久々 だ。

桟積みしてまたしばらくシーズニング。

FF13続き。一日4,5匹づつタイマイを狩り続けている。タイマイのドロップは確 変だ。来ると9割近い確立で落とし続ける。継続範囲は4〜10体。継続している 時は実時間は関係なさそう。倒してセーブしてタイトルに戻って、1,2時間放置 してまたやって、また放置してでもずっと継続する。翌日まで放置してもOK。 なんとかこの確変を制御できないかとあれやこれや試しているのだけど、ない。 二回続けてドロップがなければ確変終了かな。
スケジューラアクティベーション続き。この論文ではアップコールの性能はカー ネルスレッドの5倍悪い。これは著者らはModula-2+のせいにしている。 しかしさすがDECだ。Modula-2+とは。

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.

5 性能

我々の研究の目標は、カーネルスレッドの機能と、それぞれのアドレス空間上
のユーザ層で並行性を管理する性能と柔軟性を組み合わせることである。機能
と柔軟性については、これまでの章で検討した。性能の点で、三つの問題を検
討する。一つは、このシステムでユーザ層スレッド操作(即ち fork, block,
yield)のコストはどの程度か? 二つ目に、カーネルとユーザ層の間の通信コス
ト(具体的にはアップコール)はどうか? 三つ目は、アプリケーションの性能に
全体としてどの程度影響があるか?

5.1 スレッドの性能

ユーザ層スレッド操作のコストは、この研究の前からFireflyで使われていた
FastThreadsパッケージ(これはTopazのカーネルスレッドの上で走行する。シス
テムとの統合性は貧弱である)のそれと本質的には同じである。表4には、表1に
あった、元のFastThreads、Topazのカーネルスレッド、Ultrixプロセスのデー
タに今回のシステムのデータを追加した。

表4 スレッド操作の待ち時間 (usec)
----------------------------------------------------------------------------------------
		FastThreads on	FastThreads on		
Operation	Topaz threads	Scheduler Activations	Topaz threads	Ultrix processes
----------------------------------------------------------------------------------------
Null Fork	34    		37	  		948   		11300
Signal-Wait	37		42			441		1840
----------------------------------------------------------------------------------------

我々のシステムはユーザ層スレッドをカーネルスレッドの上で提供する利点を
そのまま保っている。Null Forkでは3usec元のFastThreadsより悪くなっている。
これは実行中のスレッドの数を増減することと、カーネルに通知するかを決定
することによる(単一プロセッサのマシン、あるいは利用可能なできるだけ多く
のプロセッサを常に要求する十分な並列性がある場合は、この部分はなくすこ
とができる)。 Signal-Waitでは5usecの悪化している。これは横取りされたス
レッドが再開しているのかどうか(その場合は、条件コードを復帰する余分な仕
事をしないとならない)を調べるコストによる。カーネルスレッドよりはまだ一
桁ほど性能がいいが、4.3章で述べたロックを保持した時のゼロオーバーヘッド
のやり方なしでは、とても性能が悪くなる。この最適化なしでは、Null Forkは
49usecに、Signal-Waitは48usecになる。(Null ForkはSignal-Waitにくらべて
より多くのきわどい領域がある)

5.2 アップコールの性能

スレッドの性能(5.1章)では、頻繁に起こる(カーネルとの関与のない)状況につ
いての特性を示した。アップコールの性能、これはまれに起こる状況であるが、
いくかの理由により重要である。一つは、損益分岐点を決定するのに役立つ。
カーネルスレッドより性能がよくなりはじめるのに必要な、ユーザ層で実行で
きるスレッド操作と、カーネルの関与が必要なスレッド操作の比である。もし、
ユーザ層スレッドをカーネルからスケジューラアクティベーションを使ってブ
ロックあるいは横取りするコストがカーネルスレッドのそれと同等であれば、
スケジューラアクティベーションは単一プロセッサ上では現実的には同じにな
りえる。さらに、スレッドが横取りされた時と、アップコールによってそれが
再スケジュールされた時の間の待ち時間によって、横取りされたスレッドが保
持しているきわどい資源のために、アプリケーションの他のスレッドがどの程
度待たないといけないかが決定される。

この実装を開始した時、アップコールの性能はTopazのカーネルスレッド操作と
同じくらいと期待していた。我々の実装はそれに較べて相当遅い。アップコー
ルの性能を測定の一つは、二つのユーザ層スレッドがカーネルを通してシグナ
ルし、それを待つ時間である。これは表4のSignal-Waitテストとその同期がカー
ネルによってなされるという点以外では類似している。これは、I/O要求やペー
ジフォルをスケジューラアクティベーションによって開始し、完結するオーバー
ヘッドの近似する。そのSignal-Wait時間は2.4msecでTopazスレッドより5倍性
能が悪い。この違いの原因となる、スケジューラアクティベーション固有の問
題はみつからない。それは二つの実装問題のせいである。一つはスケジューラ
アクティベーションをTopazのカーネルスレッドシステムのてっとりばやい改造
として作成したこと。もっと整備しなくてばならず、これをスクラッチからカー
ネルに設計した場合にくらべてオーバーヘッドがあるということ。重要なのは
Topazのスレッドシステムはアセンブラによって慎重に最適化されて書かれてい
る。我々のカーネル実装は完全にModula-2+によって書かれている。比較として、
SchroederとBurrows[19]はSRC RPCの処理コストをModula-2+からアセンブラに
書き直すことで4倍以上減らした。従って、最適化されれば、アップコールの性
能はTopazのカーネルスレッドの性能と同程度になると期待する。結果として、
次章のアプリケーションの性能の測定は、製品レベルのスケジューラアクティ
ベーションの実装よりは幾分悪い結果となる。

スケジューラアクティベーション続き。4.3章のI/Oした時のカーネル/ユーザを またぐ回数の記述が納得できない。スケジューラアクティベーションならI/Oで ブロックしてそれが再開されるまでの間にブロックしたことを知らせるアップ コールが一度は入らないといけない。これがなければI/Oでブロックしたスレッ ドコンテキストを別のスレッドに移すことができないから。I/Oが完了した時は 運がよければ一回ですむ。なのでカーネルスレッド2回に対してスケジューラア クティベーションは最低でも3回だろう。

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.

カーネルのプロセッサ割当てはそれぞれのアドレス空間がより大くのプロセッ
サを使えるか、あるいは遊んでいるプロセッサがあるかの情報についてだけ知っ
ていればよい。(アプリケーションはどちらの状態でもないこともある。例えば、
プロセッサを要求し、それを受けとり、さらにプロセッサを要求することがな
い場合) 3.2章で述べたインターフェースによってスケジューラアクティベーショ
ンを使うアドレス空間からこの情報が提供される。カーネルスレッドを直接使っ
ているアドレス空間では、カーネル内部データによってこの情報は提供される。
スケジューラアクティベーションを使っているアドレス空間にはプロセッサは
アップコールを通してユーザ層のスレッドスケジューラに割当てられる。カー
ネルスレッドを使っているアドレス空間には元のTopazスレッドスケジューラに
プロセッサが割当てられる。結果として、プロセッサの静的な分割の必要がな
い。

4.2 スレッドスケジュールの方針

我々の設計の重要な面は、カーネルはアプリケーションの並行性モデルやスケ
ジュール方針、ユーザ層を並行性を管理するデータ構造について関知しないこ
とだ。アプリケーションのそれぞれは、これらについて適切なものを完全に自
由に選ぶことができ、そのアプリケーションに合わせて最適化することもでき
る。FastThreadsの規定の方針はプロセッサ毎の実行待ち行列を各自のプロセッ
サがLast-In-First-Outの順番である。これはキャッシュ局所性のためで、プロ
セッサは自分の実行待ち行列が空になったら仕事を探しにいく。これは本質的
にMultilisp[10]で使用されている方針である。

追加として、我々の実装では不必要なプロセッサの再割当てを防ぐために、履
歴効果を含んでいる。アイドル状態になったプロセッサはそれをカーネルに再
割当て可能と通知する前に、小時間スピンする。

4.3 性能向上

ここまでで述べた設計で、ユーザ層スレッドにカーネルスレッドと同等の機能
を提供するのには十分だが、その性能に対して重要ないくつかの考察がある。

これらのうち一番重要なのは3.3章で述べたきわどい領域に関する部分である。
ユーザ層スレッドが横取りされた時(あるいはカーネル内でブロックしたり、再
開可能になったとき)、きわどい領域を一時的に継続させるために、ユーザ層ス
レッドシステムはスレッドがロックを保持しているかどうかを調査できるよう
になっていないとならない。これの一つの方法として、きわどい領域に入った
らスレッドにフラグを立て、出る時にクリアする、そしてこれで継続している
かどうかを調べる。一時的に継続して実行されたスレッドが、それが安全な場
所まで来た時、プロセッサを放棄して元のアップコールに戻るのに、その調査
が必要である。あいにく、これはページフォルトや横取りが起きても起きなく
ても(これらはそう頻繁ではないにもかかわらず)、ロックの獲得と解除のオー
バーヘッドが大きい。これらの頻繁に起こるきわどい領域をユーザ層スレッド
システムの構築に使っているので、遅延時間はとりわけ重要である。

我々は一般的な場合にオーバーヘッドのない別の解決法を採用した。関連する
技術は、単一プロセッサ上のTrellis/Owlのガベージコレクタ[17]で使われてい
た。低層のすべてのきわどい領域の正確なコピーを作る。これは特別なアセン
ブラのラベルを使って、ユーザ層スレッドシステムのCのソースコード内のきわ
どい領域のそれぞれの区切りでこれを行なった。そして、コンパイラの生成し
たアセンブリコードを後処理して、コピーをした。これは言語とコンパイラの
支援があれば素直にやれるだろう。コピーの終了で、元の版とは違うきわどい
領域、プロセッサを放棄して再開するところに返るコードを置く。普通の実行
では元のコードを使う。横取りが起きると、カーネルは新しいスケジューラア
クティベーションをユーザ層への通知のために開始する。このアクティベーショ
ンは横取りされたスレッドのプログラムカウンタが、これらのきわどい領域の
どれかに該当しているかを調べ、もしそうであれば、対応するこれらのきわど
い領域のコピーの一つからスレッドを継続する。そのコピーによってきわどい
領域が終わったところで制御を放棄し、元のアップコールに戻る。普通の実行
では元のコードを使い、これは横取りに対処する処理を入れる前とまったく同
じコードなので、通常の場合ではまったくロックの遅延がない。(我々の実装で
は、時折きわどい領域の中で手続き呼出しをしなくてはならない。この場合、
直線経路ではなく、明示的なフラグをセット/クリアすることによって呼出しを
ひとまとめにする。)

二つ目の性能向上に重要なことは、スケジューラアクティベーションの管理に
関連することである。論理的にはそれぞれのアップコールに対して新しいスケ
ジューラアクティベーションが作成される。新しくスケジューラアクティベー
ションを作成するのには、そのデータ構造を割当て、初期化することが必要な
ため、制約がないわけではない。その代わりに廃棄されたスケジューラアクティ
ベーションを、いずれ再利用される時のためにとっておくことができる。ユー
ザ層スレッドシステムは、それまで実行していたスレッドがそのコンテキスト
から削除されたらすぐにそのアクティベーションをカーネルに返すことで、古
いスケジューラアクティベーションを再利用することができる。横取りの場合
では、ユーザ層に横取りを通知するアップコールを処理した後に。カーネル内
でブロックした場合では、ユーザ層に再開が可能であることを通知するアップ
コールの処理をした後に。似たような最適化は多くのカーネルスレッドの実装
で使われている。カーネルスレッドが一度作成されたら、破棄する時でもとっ
ておいて、この先のスレッドの作成を速くする[13]。

さらに、廃棄されたスケジューラアクティベーションを、一回ごとに返すので
はなく、集めておいてカーネルに一括して返すことができる。時折の廃棄の一
括返還を無視して、我々のシステムではI/Oやプロセッサ横取りでアプリケーショ
ン-カーネル境界をまたぐ回数を、伝統的なカーネルスレッドのシステムと同じ
にしている。カーネルスレッドのシステムでは、I/Oの初まりで一回、そして
I/Oの終了でもう一回、(カーネル/ユーザ)境界を越える。我々のシステムでも
同じカーネル境界の通過がある。

4.4 デバッグの考慮

Firefly Topazデバッガにスケジューラアクティベーションを統合した。二つの
分けられた環境があり、それぞれに要求がある: ユーザ層スレッドシステムの
デバッグと、スレッドシステムの上で動くアプリケーションのデバッグである。

透過性はデバッグには重要である。デバッガはデバッギの命令の並びにできる
限り影響がないようにするべきだ。前述のカーネルサポートではユーザ層スレッ
ドシステムにそれぞれの物理プロセッサの状態を通知するが、これはスレッド
システム自体がデバッグの対象となる場合には不適切である。代わりに、カー
ネルはそれぞれのスケジューラアクティベーションにデバッグする論理プロセッ
サを割当てる; デバッガがスケジューラアクティベーションで停止あるいはシ
ングルステップをした時には、これらの事象はユーザ層へのアップコールの対
象とならない。

ユーザ層スレッドシステムが正しく動いていると想定すると、デバッガはスレッ
ドシステムの機能を使って、ユーザ層スレッドのコンテキストで走行している
アプリケーションの状態を停止したり、調べることができる。

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

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アプリケーションを(この先も)実行できるようにするにはカーネルスレッ
ドもサポートしないといけないからだ。この実装では、カーネルスレッドを使
うアドレス空間は、スケジューラアクティベーションを使うアドレス空間と同
じやり方でプロセッサを獲得する。

スケジューラアクティベーション続き。カーネルでの役割りはアドレス空間に プロセッサ割当てることだけで、どれだけ割当てるかはユーザ層からの要求に よって決定する。となるとユーザ層がとりたいだけプロセッサをとろうとした 時にどう対応するのか。結局はカーネルでのプロセッサ割当ても時分割にしな いといけないのでは?そうなると時分割で横取りされたということをその度アッ プコールでユーザ層に伝えないといけない。結構なオーバーヘッドだ。1:1なら いくらカーネルの中で時分割してもユーザ層との通信はない。スケジューラア クティベーションならできる限り時分割にはしたくない。逆に時分割でなけれ ば、まだ相性はいいのかも?

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.


三つめは、ユーザ層スレッドがまったく走行していない時にユーザ層スレッド
スケジューラの中で横取りやページフォルトが起きたとしても、スケジューラ
アクティベーションは適切に動作するということ。この場合、スレッドスケ
ジューラの状態はカーネルに退避される。その次に続くアップコールではもし
ユーザ層スレッドが走行中であれば、あるやり方で(再入可能な)スレッド管理
システムを再開し、走行中でなければ別のやり方で再開する。それは新しいア
クティベーションとそのスタック上で行なわれる。例えば、横取りされたプロ
セッサがアイドルループだったとしたら、何もする必要がない; もしアップコー
ル中に事象を処理している時であれば、ユーザ層のコンテキストスイッチは引
き続き事象を処理することができる。カーネルに追加される厄介な問題はプロ
グラムのページフォルトを通知するアップコールは同じ場所でまたページフォ
ルトするかもしれないことだ。カーネルはこれを調査しなくてはならなく、も
しこの状態が起きたら、ページフォルトが完了するまでアップコールを遅延す
る。

最後に、カーネル内でブロックされたユーザ層スレッドは、I/O完了の後、カー
ネルモードでさらに実行する部分があるかもしれない。そうであれば、カーネ
ルはもう一度ブロックするか、あるいはカーネルからユーザ層に戻るところま
でを一時的にスレッドを再開し実行する。後者が起った場合にはカーネルはユー
ザ層に通知し、ユーザ層スレッドのレジスタ状態をアップコールと一緒に受渡
す。

3.2 プロセッサ割当てに影響を与えるユーザ層の事象をカーネルに通知すること

3章の残りで述べる機構は、カーネルのアドレス空間の間でどうプロセッサを割
当てるかの方針とは独立である。しかしながら合理的な割当て方針はそれぞれ
のアドレス空間で利用される並行性モデルに基づかねばならない。ここでは

走行可能なスレッドが存在しない時にはプロセッサをアイドル状態にしないこ
とを保証し、優先度を大事にする方針のために、この情報が効果的に通信され
ることを示す。

これらの束縛は我々の知る限り、ほとんどのカーネルスレッドシステムに存在
し、カーネルスレッドの上にユーザ層スレッドシステムを構築した場合には存
在しない。重要な点は、ユーザ層スレッドシステムはスレッド操作についてな
にもカーネルに通知する必要がないだけでなく、いくつかの操作についてを(カー
ネルに伝えることで)カーネルのプロセッサ割当ての決定に影響を与えることが
できる点である。対照的に、カーネルスレッドを直接使った場合、次に走るス
レッド(オーバーヘッドを最小化し、キャッシュを持続させる一方、優先度に従っ
て選んだ)が同じアドレス空間のスレッドだったとしても、カーネルにトラップ
しないといけない。

我々のシステムでは、アドレス空間は、プロセッサより多くのスレッドが必要
になったり、走行可能なスレッドよりプロセッサが存在する時のように状態が
以降する時に、カーネルに通知する。アプリケーションが実行するのに余分な
スレッドを提供し、それに追加のプロセッサを割当てないのなら、システムの
全てのプロセッサは稼働中にならないとならない。さらに並行度を上げること
ではの束縛を破れない。同様に、アプリケーションがアイドル中のプロセッサ
があることをカーネルに通知して、カーネルがそれを取り上げない場合は、シ
ステムには他に仕事がない状態でないとならない。カーネルはアイドル中のプ
ロセッサが追加された通知を受ける必要がない。(このやり方の拡張で、アドレ
ス空間よりはむしろスレッドが全体的な優先度をもつ状況を処理することがで
きる)

表3には、これらのアドレス空間での状態の遷移によって呼び出されるカーネル
呼出しを一覧にした。例えばアドレス空間がカーネルにより多くのプロセッサ
が必要だと通知した時、アイドル中のプロセッサがあると登録されたアドレス
空間から探す。もしみつからかった時は、何も起こらない。しかし、この先ど
れか一つのプロセッサがアイドル状態になれば、最終的にこのアドレス空間は
プロセッサを獲得する。これらの通知はヒントでしかない: もしカーネルがア
ドレス空間にプロセッサを与え、その時にはもはや必要なかった場合、単純に
アドレス空間は更新された情報とともにプロセッサをカーネルに返す。もちろ
んその通知は順序の問題があるので、順序つけて通知しないといけない。

----------------------------------------------------------------------
表3 アドレス空間からカーネルへの通信

もっとプロセッサを追加せよ(追加として必要とされるプロセッサの数)

カーネル→より多くのプロセッサをこのアドレス空間に割当て、スケジューラア
	 クティベーションを実行して開始する。

このプロセッサはアイドル状態()
カーネル→このプロセッサを横取りして、他のアドレス空間に割当てる。

----------------------------------------------------------------------

このやり方の明らかな欠点は、アプリケーションのその並行度のOSへの通知が
正当でないかもかもしれないことだ。この問題はマルチプロセッサに特有の問
題ではない。正当でない、あるいは、間違ったプログラムは単一プロセッサ上
の並行処理でも不当に資源を獲得することができる。ユーザ層かカーネル層の
どちらかにおいて、多層のフィードバックによってアプリケーションにプロセッ
サの割当ての決定に対して正当な情報を提供するように促すことができる。プ
ロセッサの割当てにおいて、少ないプロセッサを使うアドレス空間の優先度を
高くし、多く使うアドレス空間は低くする。これによって他のどこかでプロセッ
サが必要な時にはアドレス空間にプロセッサを明け渡すことを促すことができ
る。優先度を示すことで、プロセッサが必要な時に返ってきそうだからだ。そ
の一方で、システム全体でプロセッサの数よりもスレッドの数が少ない場合に
は、アイドル状態のプロセッサは近い将来使われる時のためにそのアドレス空
間に留っているべきであり、これによってプロセッサ再割当てのオーバヘッド
を回避することができる。

多くの単一プロセッサOSでは、似たようなことをする。平均応答時間、とりわ
け対話処理の性能は、残りの時間が最少のジョブを優先することで改善され、
それはしばしば、実行時間の合計によってジョブの優先度を減らすことで近似
される。似たような方針をマルチプロセッサ上の並行処理に使うことで、同じ
結果が得られると期待する。この方針によって簡単にアイドル状態のプロセッ
サについて正しい情報を報告するようにしむけさせれる。

3.3 きわどい領域

これまでに検討していなかった問題の一つは、ユーザ層のスレッドは、ブロッ
クされたり横取りされたりする時に、きわどい領域を実行していることがあり
得る。(1
----------------------------------------------------------------------
(1 きわどい領域はwait-free同期[11]を使えば必要なくなるだろう。しかしな
がら、多くの商用プロセッサでは、wait-free同期を実装するのに必要なCPU命
令がない(我々は原子的なtest-and-setだけを想定している)。さらに、
wait-free同期のオーバーヘッドはとても小さなデータ構造を保護するには大き
過ぎることになるかもしれない。
----------------------------------------------------------------------

二つの悪影響がある。性能の悪化(他のスレッドはその横取りされたスレッドの
アプリケーションがロックしたままのスピンロックを取ろうとする)[28]、そし
てデッドロック(横取りされたスレッドが実行待ち行列のロックを保持している
こともあり得る。その場合、アップコールによってその割込まれたスレッドを
実行待ち行列に置こうとした時にデッドロックする)。きわどい領域がロックに
よって保護されていない場合でも起きる。

FF13続き。ホプライスレを見ていたらヴァイルピークスからやりたくなり、4章 のセーブデータからやっていた。スニーク使いまくりで。ボス戦も今からやり 直してみると、きちんと強化弱体してやればどってことなかったんだな...。
オーディン後から戦闘時の声の掛け合いがはじまる。亀狩りの毎日にはいい清 涼剤だ。
これが見れるのはオーディン倒伐後。焦燥感でヒステリックにパニクっていた ライトさんが落ちつきを取り戻すところだ。オーディンは今やってもぎりぎり だった。

スケジューラアクティベーション続き。スケジューラアクティベーションにす るとI/Oやページフォルトでブロックされた時のカーネルとユーザ層の通信は 1:1のカーネルスレッドよりも多くなる。ここは不利なのだけど、それ以外の操 作はユーザ層だけで済むことで、全体の時間的には優位になるのか、ならない のかというとこか。

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.

表2にスケジューラアクティベーションによってカーネルからユーザ層に伝達さ
れる事象を一覧にした; それぞれのアップコールの引数は括弧で、ユーザ層ス
レッドシステムにによる動作は斜体。

----------------------------------------------------------------------
表2 スケジューラアクティベーションがアップコールする場所

+ このプロセッサを追加する(プロセッサ番号)
ユーザ層→走行可能なユーザ層スレッドを実行する

+ プロセッサが横取りされた(横取りされたアクティベーション番号とそのマシン
状態)
ユーザ層→横取りされたスケジューラアクティベーションで実行していたユーザ
	 層スレッドを走行待ち行列に戻す。

+ スケジューラアクティベーションがブロックした(ブロックしたアクティベー
ション番号)
ユーザ層→ブロックされたスケジューラアクティベーションはもはやそのプロ
	 セッサを使用していない。

+ スケジューラアクティベーションがブロックから復帰した(復帰したアクティ
ベーション番号とそのマシン状態)
ユーザ層→ブロックされたスケジューラアクティベーションで走行してたユー
	 ザ層スレッドを走行待ち行列に戻す。
----------------------------------------------------------------------

カーネルがスケジューリングの決定を他のものにする場所で正確に事象が伝達
されることを注記する。実際には、これらの事象は組み合わせで起き、それが
起きた時には一回のアップコールによって取り扱う必要のある全ての事象が伝
達される。

スケジューラアクティベーションの使い方の一つの例として、図1はI/O要求、
終了において何が起こるかを図解している。これはまれな状況であることを注
記する; 普通の操作では、カーネルの介入なしにスレッドは作成され、走行し、
終了する。図1のそれぞれの枠は異る時間ステップを表している。まっすくの矢
印はスケジューラアクティベーションを表し、S字の矢印はユーザ層のスレッド
を表し、それぞれの枠の右側にあるユーザ層スレッドの固まりは実行待ち行列
を表している。

時間T1では、アプリケーションにはカーネルによって二つのプロセッサが割当
てられた。それぞれのプロセッサでカーネルはユーザ層のコードをアップコー
ルし、そこで実行待ち行列からスレッドを外し走行開始させる。時間T2では一
つのユーザ層スレッド(スレッド1)がカーネル内でブロックした。この事象をユー
ザ層に通知するために、スレッド1で走行していたプロセッサをとり、新しいス
ケジューラアクティベーションとしてアップコールを実行する。そしてユーザ
層スレッドスケジューラはそのプロセッサを使って実行待ち行列の中のスレッ
ドを走行させることができる。

時間T3では、I/Oは終了した。再びカーネルはこの事象をユーザ層スレッドシス
テムに通知しなければならないが、この通知にはプロセッサを必要とする。カー
ネルはそのアドレス空間内で走行しているプロセッサの一つを横取りし、それ
を使ってアップコールする。(もしI/Oが完了した時、そのアドレス空間に一個
もプロセッサが割当てられていなかった場合、このアップコールはカーネルが
プロセッサが割当てるまで待たないとならない)

このアップコールによってユーザ層にはI/O終了と横取りの二つの事が通知され
る。アップコールによってユーザ層のコードは二つの事をすることが求められ
る(1) ブロックされたスレッドを実行待ち行列に置く。(2) 横取りされたスレッ
ドを実行待ち行列に置く。この段階でAとBのスケジューラアクティベーション
は放棄してよい。最終的に時間T4でアップコールは実行待ち行列からスレッド
をとってきて、それを実行開始する。

ユーザ層のスレッドがカーネルの中でブロックしたり横取りされた時、既にユー
ザ層の段階でそれを再開するのに必要な状態のほとんど、すなわちスレッドス
タックと管理領域である。しかしながら、スレッドのレジスタ状態はカーネル
の割込みハンドラや、ページフォルトハンドラのような低層で退避される。カー
ネルはこの状態を、I/O完了や横取りをアップコールによってアドレス空間に通
知する時に一緒に受渡す。

我々はまったく同じ機構を多重処理のためのアドレス空間の間でのプロセッサ
の再割当てに用いている。例えばカーネルがあるアドレス空間からプロセッサ
を取り上げ、他に与えるとする。プロセッサに割込みをかけ、アクティベーショ
ンを停止し、そのプロセッサを使って他のアドレス空間へ新しいアクティーベ
ションとともにアップコールすることによってなされる。カーネルは事前に前
のアドレス空間にその許可を得る必要はない。許可を得るようにすると、アド
レス空間の優先度を破るかもしれない(例えば、新しいアドレス空間は古いアド
レス空間よりも高い優先度でもあり得る)。それでも古いアドレス空間はその横
取りが起ったことを通知されないといけない。カーネルはこれを古いアドレス
空間でまだ走行している他のプロセッサを横取りすることによって実行する。
その二番目に横取りされたプロセッサは、古いアドレス空間に向って新しいス
ケジューラアクティベーションとともに、そのアドレス空間では「二つ」のユー
ザ層スレッドが停止されたことを通知することに使われる。そしてユーザ層の
スレッドスケジューラはこれらのスレッドをどう残りのプロセッサ上で実行す
べきかを制御する(アドレス空間の最後の一つのプロセッサが横取りされた場合
は、そのアドレス空間からの横取りをしない。その代わりに、このアドレス空
間にプロセッサに再割当てされた時までその通知を遅延する。通知によってユー
ザ層はどのプロセッサが割当てられたかを知ることができる。そしてこれは明
示的にキャッシュ局所性を管理するのに使える)。

 上記ではとても単純化していて、いくつかの考慮する点がある。一つは、もし
スレッドに優先度があった場合には、上記の例にさらに追加の横取りが必要に
なるかもしれない。例えば図1では、スレッド3はスレッド1,2より低い優先度だっ
たと想定しよう。この場合ユーザ層スレッドシステムはカーネルにスレッド3の
プロセッサを横取りしてもらうように求めることができる。そしてカーネルは
そのプロセッサを使って、ユーザスレッドシステムがスレッド3を実行待ち行列
に入れ、その代わりにスレッド2を走らせることができるようにアップコールを
するだろう。ユーザ層はどのスレッドがどのプロセッサで走行しているかを正
確に知っているので、追加の横取りを求めることを知ることができる。

二つ目に、カーネルがユーザ層スレッドを停止し、そのコンテキストを保存し
ているように記述しているが、カーネルとアプリケーションの相互作用は全て
スケジューラアクティベーションによってなされる。アプリケーションはスケ
ジューラアクティベーション上で、どのような並行性モデルでも構築できる。
つまりカーネルの挙動はどのような場合でもまったく同じである。特記するの
はカーネルはユーザ層での並行性を実現するデータ構造についてまったく知る
必要がないことだ。

三つめは、ユーザ層スレッドがまったく走行していない時にユーザ層スレッド
スケジューラの中で横取りやページフォルトが起きたとしても、スケジューラ
アクティベーションは適切に動作するということ。この場合、スレッドスケ
ジューラの状態はカーネルに退避される。その次に続くアップコールでは

筑波一戦のエントリしました。もうそろそろCR85も作りはじめないと。
FF13続き。タイマイ狩り。ロールはカンスト、最強武器にまでした状況でデス 狩りもないだろう。ということで(と、どうもデスの効きが悪い状況が続き..) ガチ狩りに。ニコ動でよさ気な戦略は押さえておいたのでそれを真似て。しか しうまくいかない。なんでうまくいかないかというと、操作がゆっくりだった り失敗したりするから。なんとか操作にも慣れてきて、確実に狩れるようにな りました。そこからまた人選を変えてみたりしてさらに安定するまでに一苦労。 サッズを使っていきたいんだよね。ファング/ヴァニラ/サッズで。

B/J/B これで両足ブレイク。最初ブレイクした足はそのまま。そのためのJか?
A/H/B 両足それぞれハイウィンドで倒しつつ回復。
E/J/B ブレイダ/フェイダ/ヘイストを配給
B/B/B ここで何%でA/A/Aに切り替えるかがポイントなのだけど、このPTの時は
待った方がいいのかブレイク即がいいのか迷い中。ブレイク即でも安定。
A/A/A 立ちあがったところでハイウィンドでなんとか間に合う。

のパターン。ニコ動だとサッズじゃなくホープ。
でもやっぱりデスの方が性に合ってるな...。無用な緊張は嫌なんだよ。
スケジューラアクティベーション続き。

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.

3.1 カーネル事象をユーザ層スレッドスケジューラに誘導する詳細

カーネルのプロセッサ配分と、ユーザ層スレッドシステムの通信は「スケジュー
ラアクティベーション」によって構造化される。「スケジューラアクティベー
ション」という言葉は、それぞれの誘導された事象がユーザ層スレッドシステ
ムに、どのプロセッサでどのスレッドを走行させるかの計画の判定し直させる
ことになるということから選ばれた。

スケジューラアクティベーションは三つの役割を務める。

 - ユーザ層のスレッドが走行するための実行コンテキストになる。これはカー
   ネルスレッドがしていたこととまったく同じやり方である。

 - ユーザ層スレッドシステムにカーネル事象を通知する。

 - スレッドがカーネルによって停止された時(例えばI/Oや、カーネルがプロセッ
   サを横取りすることによって)、スケジューラアクティベーションの目下の
   ユーザ層スレッドのプロセッサコンテキストをカーネル内で退避しておく場
   所として。

スケジューラアクティベーションのデータ構造は伝統的なカーネルスレッドの
それとまったく似たようなものである。それぞれのスケジューラアクティベー
ションは二つの実行時スタックを持つ - 一つはカーネルに割当てられ、一つは
アプリケーションのアドレス空間に割当てられる。ユーザ層スレッドのそれぞ
れは、そのユーザ層のスタックを走行を開始する時に割当てられる[2]; ユーザ
層スレッドがカーネルの中に入ったら、そのスケジューラアクティベーション
のカーネルスタックを使う。ユーザ層スレッドシステムはスケジューラアクティ
ベーションのユーザ層のスタックで走る。加えて、カーネルはアクティベーショ
ン管理領域(スレッド管理領域に似たもの)を、そのスレッドがカーネル内でブ
ロックしたり横取りされた時に状態を保存しておき、ユーザ層スレッドスケ
ジューラはどのユーザ層スレッドがどのスケジューラアクティベーション上で
走行しているかの記録を保守する。

プログラムが開始されると、カーネルはスケジューラアクティベーションを作
成し、それにプロセッサを割当て、アプリケーションのアドレス空間の固定さ
れた入口にアップコールする。ユーザ層スレッド管理システムは、そのアップ
コールを受け、そのアクティベーションを実行コンテキストとして自分自身を
初期化し、アプリケーションスレッドを走行させる。最初のスレッドが実行さ
れ、さらにユーザスレッドを作成し、追加のプロセッサを要求するかもしれな
い。この場合、カーネルはそれぞれのプロセッサに対してスケジューラアクティ
ベーションを作成し、それを使ってユーザ層にアップコールし、新しいプロセッ
サが利用可能なことを通知するだろう。そしてユーザ層は、そのアクティベー
ションのコンテキストで走行するスレッドを選択し、実行させる。

同様に、カーネルが事象をユーザ層に通知する必要がある時には、カーネルは
スケジューラアクティベーションを作成し、それにプロセッサを割当て、アプ
リケーションのアドレス空間にアップコールする。一旦アップコールが開始さ
れるとアクティベーションは伝統的なカーネルスレッドと似たようなものであ
る。- それはプロセス事象を処理するのに使われ、ユーザ層スレッドで走行し、
カーネルにトラップされ、カーネルの中でブロックする。

スケジューラアクティベーションとカーネルスレッドの決定的な違いは、アク
ティベーションのユーザ層スレッドが一旦カーネルによって停止されると、そ
のスレッドがカーネルによって直接復帰することはは決してないことだ。その
かわりに、スレッドが停止した事をユーザ層に通知するための新しいアクティ
ベーションが作成される。そしてユーザ層スレッドシステムはそのスレッド状
態を以前のアクティベーションから削除し、以前のアクティベーションは再利
用可能であることをカーネルに通知し、最後にどのスレッドをプロセッサで実
行させるかを決定する。対照的に伝統的なシステムでは、カーネルスレッドを
カーネルが停止した時、それがそのコンテキストでユーザ層のスレッドが走っ
ていたとしても、その事を決してユーザ層には通知しない。しばらくして、カー
ネルスレッド(暗黙的にそのユーザスレッドも)は直接カーネルによって復帰す
るが、それも通知されることはない。スケジューラアクティベーションを使う
ことによってカーネルは、アドレス空間に割当てられたプロセッサの数と、走
行しているスケジューラアクティベーション(ユーザスレッドの容れ物)の数を
同じに維持していくことが可能になる。

この寒空の中、カウルの洗浄はつらい。おまけにカウルにセンサを取りつけて しまったため、非常にやりづらい。積み込みも終了。RS125だと、正直フロント キャリパーは対向4ポッドにしたい。(今は27φの方押し2ポッド)
とはいえこのRS125、あと何回走行できるか秒読み段階だからね。 FF13続き。タイマイでプラチナインゴット4つ程とってきてとりあえずの金策は 終了。この間にトラペゾヘドロン2つ落とした。今はグッドチョイスを装備。な んとなくだけどベストチョイスよりグッドチョイスの方がいいような。
そしてまたダークマター狙いシャオロングイに。平原に戻る途中で久々に ベヒx犬を。なんと3秒台に突入した。

シャオロングイ、またいろいろ試してみた。ニコ動にはATB加速で1ターンで撃 破という例があって、何度か試してみたものの、コマンド入力中に攻撃に対応 できなくて全滅の繰り返し。コマンドウィンドゥでコマンド選んでいると、他 が見えないのよね...。
諦めて元の戦略に戻って、いろいろオプティマを変えてみたり、メンバを変え てみたりしてみたところ、スノウをサッズに変えてみるとかなりいい感じに。 フォーマルハウトLv40と、攻撃力はない武器なのだけど、チェーンボーナスUP 改が効いてる感じ。ブレイク後の削りがとてもいい。途中でアルテマがなめれ ばそのまま削り切れる勢いだ。
ということで、シャオロングイ狩りはファング/サッズ/ヴァニラに。調子にのっ てフォーマルハウトLv40は有り金全部使ってトータルエクリプスLv72に。

攻撃力は低い。が、あなどれない。



オプティマは

E/E/J
J/E/H
J/B/H
A/A/A
H/H/H
D/D/D

ここでE/E/Jは仕方なく入れた。スノウのENHの場合、まず自分にヘイスト入れ て、まずヘイストから配ってくれるのでうれしいのだけど、サッズはなかなか ヘイストを入れてくれない。なので手動でヘイストを入れる用。本当はB/B/Hを 入れたいのだけど...。スノウのENHのモーションは彼らしく暑苦しくていい。

と、いろいろやっているうちにギルがすっからかん。またタイマイかな...。

RS125整備。そこらに転がっていた自転車のサドルステムの切れ端からフランジ を作成。これでどのくらいもつか。
象の鼻の部分のガスケットには、0.27mmのトタン板を8x150に切って巻いてみた。

腰上組んで、チェーン洗って終了。ピストンリングは新品に。あと3つ程残って いる。次もこいつで走りに行きます。

FF13続き。

ミッション五つ星化には耐性装備が必要。
	↓
アクセサリの改造。
	↓
ダークマターが必要。
	↓
シャオロングイ狩り。
	↓
火力が足りない。
	↓
火力UPアクセサリを改造しようにもこれにもダークマターが必要
	↓
全財産使って武器を改造。
	↓
なんとか倒せるようにはなってきたけれど、まだまだ強化が必要。
	↓
金策にタイマイ狩りするか..

と、またタイマイ狩りに戻ることに。とはいえここまででなんとかシャオロン グイを倒す手段が見えてきた。(ニコ動とかyoutubeだと、ベスト装備だったり、 プレイヤーがうまかったりして、ヒント程度にしかならない。実際にやり初め てから動画を見直すとそのプレイのうまさに驚く)
シャオロングイはさんざ試してみたところ今のところだと、このあたりがベス トか。ランス・オブ・カインはニムロッドピアスベースに作ればよかった。こ れはブレードランスがベースなので物理が伸びない。

ギル不足でセイブ・ザ・クイーンのレベルは途中まで。これはエナジーサーク ルがベース。これはいい選択だったかも?

ヴァニラはベラドンナワンドベース。これは狙って。

全員、大地の指輪Lv★と月虹のアンクレットLv★でクエイクとほえる対策。後 はブレイク後の削りに振っている。アルテマをD/D/D以外で受けると即死。
オプティマはこんなところに落ちついた。最初スノウのかわりにライトさんだっ たのだけど、スノウの方が安定する感じ。

開幕のクエイク受けにD/D/Dで入り、J/E/Jでチェーンを稼ぎながら強化。クエ イクはそのまま受けてしまう。ダルが入る頃にはそろそろブレイクなので、ダ ルが入った瞬間を狙ってE/E/Hに。ここで足りない強化を手動で入れてHPが回復 したところで、A/A/Jでブレイク(JAMが入ってるのはできる限りダルを入れ続け れる状態をキープしたいため)。一回目のブレイクだと次、ハイウィンド...と いう時にアルテマが来てD/D/Dで受けているうちにブレイクが終わってしまう。 次のブレイクまではJ/B/Hで。このあたりのクエイクはD/D/Dで受ける。二回目 のブレイクで削り残すとまず難しい。ダルが入った時の時間をうまく使えると こっちのペースにもっていけるのだけど、なかなか難しい。
特に最後、次のターンでハイウィンドでとどめ、という時にアルテマ喰らうと きつい。そのあたりで強化は切れるし、攻撃のペースは早いし。ブレイクに入 る前にアルテマが来るまでD/D/Dで待って時間調整して、ブレイクに入った方が いいのかも。
二回に一回は失敗してます。

シロッコファンの周辺はこんな感じに。建物自体が歪んできているのでいろい ろ調整が大変。この程度の距離でも鴨居が5mm歪んでいる。多少吸気音が増大し たような気もするけれど、他の木工機械の騒音に較べればどってことないレベ ル。作業中はイヤーマフしてるし。

FF13続き。今日もカメにデス。プラチナインゴットを二つゲット。クリ上げきっ てからはCP稼ぐ必要ないのでドロップがなければリセットしてやり直していた のだけど(召喚用にTP稼ぐ手間を省くため)、CPもカンスト。もっと早くから亀 亀ファンタジーに入ればよかった。
とはいえ目標のミッション五つ星化にあたっては武器の改造はあまり必要ない (攻撃力が増すと目標タイムが短かくなってしまうので)。
ここでもう一度、ミッションの攻略に必要なアクセサリの改造に立ち戻ろう か...。何やってるのかわからなくなってきた。あくまで目標はトロフィーコン プだ。

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

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.


3. ユーザ層の並行処理の管理に効果的なカーネル支援方法

2章では並行処理するのにカーネルスレッドを使った時の低性能と柔軟性のなさ
と、カーネルスレッドの上のユーザ層スレッドを使い、多重プログラムとI/Oが
存在した場合にまずい振舞いをする問題について述べた。これらの問題に取り
組むために、我々はカーネルスレッドの機能と、ユーザ層スレッドの性能と柔
軟性をとりあわせた新しいカーネルインターフェースとユーザ層スレッドシス
テムを設計した。

OSのカーネルはそれぞれのユーザ層スレッドシステムに、それが自分のものと
する仮想プロセッサを提供し、これは物理プロセッサの抽象化であるが、プロ
グラムの実行中にカーネルによってその数を変化される点が違う。この抽象化
にはいくつかの性質がある。

 - カーネルはプロセッサをアドレス空間に配分する; カーネルはそれぞれのア
   ドレス空間の仮想マルチプロセッサにどれだけのプロセッサを割当てるかを
   完全に制御する。

 - 各アドレススペースのユーザ層スレッドシステムは、それに配分されたプロ
   セッサでどのスレッドを走行させるかを完全に制御し、それはアプリケーショ
   ンが物理マシンの上で動いているかのように。

 - カーネルはユーザ層スレッドシステムに割当てるプロセッサの数を変更する
   時にはそれを通知する; カーネルはさらに、カーネルの中でユーザ層のスレッ
   ドがブロックしたり起床した時(I/Oや、ページフォルト等で)も通知する。
   カーネルの役割は事象を適切なスレッドスケジューラに誘導することで、そ
   れらを処理することではない。

 - ユーザ層スレッドシステムは、アプリケーションが必要とするプロセッサの
   数の増減が生じた時にそれをカーネルに通知する。カーネルはこの情報を元
   にそれぞれのアドレス空間に割当てるプロセッサの数を決める。ユーザ層ス
   レッドシステムはプロセッサの配分の決定にかかわりのある情報だけをカー
   ネルに通知する。これはユーザ層での操作の一部であるので性能はそう落ち
   ない。ほとんどのスレッド操作はカーネルとの通信のオーバーヘッドを受け
   ることがないからだ。

 - アプリケーションのプログラマは、直接カーネルスレッドを使ってプログラ
   ムするのと同じであり、性能だけが違う。我々のユーザ層スレッドシステム
   は、その仮想プロセッサをプログラマに透過的にし、通常のTopazスレッド
   [4]と同じインターフェースになる。(異なる並行プログラミングモデルであっ
   てもユーザ層の実行環境は簡単に適応することができる。)

この章の続きでは、どのようにしてカーネルの事象をユーザ層スレッドシステ
ムに誘導するかについて述べる。アプリケーションから提供されるどのような
情報によってカーネルはジョブ間でプロセッサの割当てをするのか、どのよう
にしてユーザ層のスピンロックを扱うのか。

工作部屋のシロッコファンが剥出しのままだったので、見栄えをよくするため の部品を作りました。今回はじめてトリマーで円をくり抜いてみた。直径の調 整がちょっと面倒だけれど、それさえ決まれば作業は早いし、仕上りは綺麗だ し、いいかも。

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]、この情報はユーザ層スレッドと深く関
わる； カーネルとユーザ層の間でこの情報をやりとりすることによって、ユー
ザ層スレッドを使うの利点である、性能や柔軟性の多くをだいなしにしてしま
う。

結局、カーネルスレッド上に構築されたユーザスレッドの論理的に正しい動き
を保証することは難しい。多くのアプリケーション、とりわけアドレス空間を
またいだ整合性が必要なものは、全ての走行可能なスレッドは最終的には必ず
プロセッサ時間を得れるという前提のもとにデッドロックを回避している。ア
プリケーションがカーネルスレッドを直接使用した時は、カーネルの時分割に
よってこの前提は保証される。しかし、ユーザ層のスレッドが、固定された数
のカーネルスレッドに多重化された場合、この仮定はもはや保証されない。カー
ネルスレッドがそのユーザ層スレッドでブロックされた場合、他の走行可能な
ユーザ層スレッドや、使用可能なプロセッサがあったとしても、アプリケーショ
ンはその実行コンテキストとしてのカーネルスレッドを失ってしまうからだ。

FF13続き。亀亀ファンタジーにはまだ難しいかと思っていたのだけど、アルティマニアによると結構いい確率でデスが効くみたい。ということで突入。アダマンタイマイ狩り。初めた頃は5ロールLv5くらい。

これがベスト記録36秒。





トラペゾヘドロンぜんぜん出ない。グロウエッグ装備だとタイマイのCP8万と TPためで1ターン10万CPたまるので、あっというまに6ロールカンスト。

トロフィー:全能のダイモンドを取得。

このアダマンタイマイ狩りの装備は、ヴァニラはできるだけ多くデスを打てるようにATB加速とオートヘイスト

ファングは適当。どっちかというとTP貯めの時用の装備。

ライトさんは「TP・ドライブUP」装備に。

またバリバリマシンをひっぱり出してきました。左から86-94。創刊号と2号は ない。3号は後に古本屋でふと見つけて買ったもの。4号がはじめてのバリマシ である。これも自分で買ったわけではなく、犬越路林道で転倒、肘の骨まで削っ て泥がついてしまい入院していて、なんでもいいからバイク雑誌買ってきてく れ〜と頼んでその中にあった一冊がバリマシだったのである。バイクに乗りは じめるにあたって、煽られると怖いし...とMTX50Rにした割に、この頃には大垂 水を通過するのがとても楽しみになっていた。この頃は東京側から神奈川側に 抜けると2ストオイルの焼ける匂いに気分が高まった。しばらくすると原付規制 になるのだけど、MTX50Rはオフなので通れた。たまに止められたけど。

自分が投稿したのや、取材で写っているのは特別に選別していたのだけど、ど うしても見つからないのが一つあった。やっと見つけた。これだ。89/10月号増 刊バリバリマシンR。本家バリバリマシンに対してバリバリマシンRはレース系 の記事が多めになっていた。

裏表紙をめくると! 87NSR時代の俺だ。手稲山の直角コーナーアプローチ。これ を探してた。懐しい。

パラパラとめくってみると...これ大治郎とノリックだ。

随分と時は過ぎたものだ。

懐しくなって、86あたりの雑誌を。モデルグラフィックスは85/10。84の創刊号 からこのあたりまであった。ホビージャパンにうんざりしていた時、これは画 期的な雑誌だった。この「とれいん」の86/3号は衝撃的な記事があり、「岩を ラテックスで型取りして、それに石膏を入れて硬化前にレイアウトに接着する」 というテクニックがあって、いたく感動した俺は、岩、岩...と、高尾山に行っ てみたところびっくりする程、岩なんてなくて、日が暮れるまで岩を探して苦 労した。この時には16になっていたけれど、バイクのバの時にも興味がなかっ た。バイクの道へと入ったのが、左上の「かっとびゼロハン大特集」そういえ ば免許とれるんだな..となんとなく笹塚の紀伊国屋で手にした一冊が。二週間 後には原付免許をとり、一ヶ月後にはMTX50Rに。
当時音楽的にはスラッシュには出会っていなくて、アメリカンハードロックを 良く聴いていた。これはナイトレンジャー特集なんだよね。春に来日して盛り上がっていた頃だ。

DJ! DJ! D-J-in my l-ife.

ハイのハイのハイのハイのハイのハイのハイのハイの、ハイのハイのハイ。

20年なんてあっという間だな。