某日記

．帰ってきたよ。

．2/8: 函館→富良野

．2/9: 富良野→帯広→占冠→富良野

．2/10: 富良野→幾寅→富良野

．2/11: 富良野→旭川→札幌→北斗星

．ＪＲ東日本の水利権取り消しへ　信濃川不正取水問題 -

真夏の電力使用のピーク時などには供給電力が不足する恐れもある。運賃の値上げについては「絶対にない」（同社）と否定している。

• 列車本数が減る。なぜか非電化区間も減る。
• 国鉄型全廃して走ルンですばっかりに。
• なぜか列車のクーラーがよく壊れる。 双子が来る。
• なぜか千葉の労務が厳しくなる。ス(ry
• 運賃上げられないので穴埋めに只見線米坂線八戸線大湊線津軽線五能線花輪線山田線岩泉線を廃止。

．「走ルンですばっかりに」は割とシャレになってないかもしれぬ。前倒しで新型に置き換えていくかもねえ。

．日本では GDP に占める外需の割合は十数パーセントなんだよな。これはアメリカの倍くらいではあるけれど、他の先進国よりはおおむね低い。私にはよくわからんのだが、なんでこれで外需依存って言われてるのかな。

．まあそれはともかく、実は今の日本の内需ってそれなりに追い風吹いてるんじゃないのかな。円高で原料を安く買えるし原油も安いから、その分国内向け商品では利ざやを稼げる余地がある。消費と設備投資の冷え込みさえどうにかして手当てできればいいんだけどねえ。

．これ - NetBSD の mutex(9) はどうなってるのかな、と見てみたら、最初っからオーナーの実行状況を見る実装になっていた。

．ところで、私も Solaris の adaptive lock といえば「1 万回スピンしてダメなら寝る」たぐいのもんだと思っていたのだけれども、UNIX Internals 見ると

Solaris 2.x の適応型ロック(adaptive lock) .... スレッド T1 は、スレッド T2 によって保有されている適応型ロックを獲得しようとする際、T2 が現在いずれかのプロセッサ上で動作していることを確認する。T2 が動作している限り、T1 はビジー待機し、T2 がブロックすれば T1 もブロックする。

．Solaris Internals は手に届くところになかったので、せっかくなので第二版をぽちっとした。

．Beyond Multiprocessing ... Multithreading the SunOS Kernel (PDF) -

The default blocking policy for mutexes, called adaptive (type MUTEX_DEFAULT), spins while the owner of the lock (recorded when the lock is aquired) remains running on a processor. This is done by polling the owner's status in the spin wait loop. If the owner ceases to run, the caller stops spinning and sleeps.

．それじゃあ「1 万回スピンしてダメなら寝る」ってのはどこから出てきた話なんじゃろか。

．しかしまあ俺も人のことは言えないけど、結局 Linus ってカーネル屋として当然調べているべきことをちゃんと調べてないってことだよなあ。15 年前のペーパーにちゃんと適切な方法が書いてあるのに。

．トーバルズ、Solarisを斬る -

　個人的には、Unixの一般原則をすべて取り入れた現在、Solarisにまだ見るべきものがあるとは思えません。今は重要と思われるすべての面で、Linuxに軍配が上がると確信しています。
　それに、もし私の考えが間違っていたとしても問題はありません。私よりSolarisを知っている人々が、Solarisの良い点を私や仲間たちに教えてくれるからです。それを自分で見つけようとするのは時間の無駄です。

．続く

．(これの続き)しろぺんさんに「社内に Solaris Internals は二冊くらいあるはず」と言われたので探したらあった。やっぱり「オーナーの実行状況見てスピンしたり寝たりする」って書いてあるなあ。

．誰か「Solaris の adaptive lock = 一万回スピンしてダメなら寝る」っていう話の出所を知ってる人がいたら連絡をください。

．KKI さんから「ググったらこういう話が引っかかった」ってメールが来た。もちろんこれ自体はユーザランドの libthread の話だから直接関係ないんだが、しかし、なんとなく糸口が掴めた気がしませんか、これ。

．つまり、Solaris ではどうも、ユーザランド側のスレッドライブラリにもスピンとブロックのハイブリッドなロックが実装されてて、これが「一万回スピンしてダメなら寝る」的実装になってるっぽい。ユーザランドで実装すると、ロックオーナーの実行状況を確認するコストが高くなりそうだから、自然とそういう実装になりそう。

．というわけで src/lib/libc/port/threads/synch.c を眺めると、やっぱりどうもそういうことらしい。

．んで、これをカーネルの adaptive lock と混同してるのが「Solaris の adaptive lock = 一万回スピンしてダメなら寝る」という話の出所なんじゃないか、という気がして来たわけです。どうでしょう。

．まとめ:

• 「Solaris 流 adaptive lock」がヒューリスティックなもの --- つまり「n 回スピンしてダメならブロックする」類のものだとするのは誤解である
• この誤解は、ユーザランド側のスレッドライブラリ実装との混同から来ていると思われる
• 実際には、ロックオーナーの実行状態を見て、実行中はスピンで待ち、ブロックしたらこっちもブロックして待つのが本当の「Solaris 流 adaptive lock」

．そういえば最近は gettimeofday(2) なんかを syscall なしで共有メモリベースでやるような方法が考案されているけれど、これを応用すればユーザランドでも真の adaptive lock を実現できたりしませんかね。

．続き

．(これの続き)風呂入ってる時にふと「SA なら userland 側もスケジューリング情報持ってるから真の adaptive lock 実現できるよな」と気づいた。

．同じ旨のメールが soda さんから来てた。

．やっぱり SA は捨てるには惜しい技術だよなあ。

．しかしそうなると、昔の Solaris は M:N スレッドなので、やっぱり userland 側でも自プロセス内の全てのスレッドのスケジューリングを管理してるはずだから、真の adaptive lock が実現できてたはずなんだよな。となると、

1. 何か理由があって昔から libthread ではヒューリスティック法だった
2. 昔は真の adaptive lock だったが 1:1 モデルに移行するときにヒューリスティック法にした

．soda さんからメール来た:

．Solaris の M:N 実装では、userland 側は「どの LWP をどのスレッドに割り付けるか」は管理していても、個々の LWP の実行状態については把握してないんですな。

．今日の wikipedia: E=mc^2 - 宇宙の物質は、物質相互の位置エネルギーと引き換えに発生してるのか。

．新型「はまかぜ」導入へ整備　ホームなど改良 - キハ 181 終了のお知らせ。まあこれはしょうがない。しかし順当に行けばキハ 187 かねえ。あの特急車両とは思えない全体的なチャチさはもうちょっと何とかならんのかな。

．このところジャズ動画ばっかり見ててそれ以外見てない。

．ニコ動はあまりジャズ動画は充実してないのだが、妙にバディリッチは人気がある。

．楽しそうすぎるタンバリン - これは BBC 1982 年制作の「Tony Sings Buddy Swings」という番組の動画らしい。とにかく 1st Tp の華麗なタンバリン捌きを刮目して見よ。

．その他のバディリッチ動画をかいつまんで:
buddy rich drumsolo 1970
Buddy Rich (rare!) drum solo
Buddy Rich Live In Holland 1978 / Grand Concourse
Buddy Rich Big Band - Mexicali Nose
アイドルマスター 「TimeCheck」
何でも叩いちゃうBuddy Rich
アニマルさんのドラムバトル

．ロック草分け鈴木茂、大麻所持で逮捕 - ううむ。