ユメのチカラ

blogのバックアップ

皆さん、blogのバックアップはちゃんと取っているのだろうか？転ばぬ先の杖。

万が一、なんらかのアクシデントでデータが消失してしまったらどうするか。インターネットの向こう側に聞いてみる。
Googleだったらurlに cache:http://blog.miraclelinux.com/yume/ などとしてキャッシュをゲットして、コピペする。

http://404.undo.jp/ というキャッシュを検索するサービスもあるらしい。
試しにやってみた。 http://404.undo.jp/http%3A//blog.miraclelinux.com/yume/

FC2ブログでユーザー記事消失　「Googleキャッシュのコピペで復帰を」
http://www.itmedia.co.jp/news/articles/0710/04/news056.html

カーネルにおけるリグレッションの特定

例えば、2.6.17では問題ないのに、2.6.18だとなぜか問題が発生するとする。linux kernel は git というソースコード管理システムによって、全ての変更が管理されているので、その機能を利用して問題を発生させたパッチを特定する事ができる。

基本的な考え方は、コミットしたパッチを問題を発生させた組と、発生しない組にわけていって、問題を絞り込む。2分検索だ。

例えば、1000個分の変更がコミットされていたとする。これを問題が発生しない状況から一個一個順ぐりにあてていき、問題が発生したら、最後にあてたパッチが原因だということがわかる。この順ぐりにあてていく場合、最悪1000回試行錯誤しなくてはいけない。

2分検索の場合、まづ、500個分あてた状態で(gitで簡単にそのような状況をつくれる)試験をし、仮に問題が発生しなければ、残りの500個に問題があるので、さらに、その半分250個をあて(最初から見ると750個のところ)試験をする。仮に問題が発生したとしたら、最初の500個分のなかに問題を発生させるパッチがあるので、さらにその半分の地点の250個分をあてた時点で試験をする。その結果によって、さらに問題を絞りこむ。

git bisectというコマンドがそれを簡単にやってくれる。手始めにOKのバージョンとNGのバージョンを設定し、その後、テストを繰り返し、テスト結果にしたがって、もし、問題が発生したら(bad)、OKであれば(good)。
git bisect bad
ないし
git bisect good
として問題をしぼりこむ。

以下実例。

# git bisect start
# git bisect good v2.6.17
# git bisect bad v2.6.18
Bisecting: 3399 revisions left to test after this
[2a2ed2db353d949c06b6ef8b6913f65b39111eab] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild
# git bisect bad
Bisecting: 1699 revisions left to test after this
[8d3c138b77f195ca0eee6fb639ae73f5ea9edb6b] page migration: Update documentation
# git bisect good
Bisecting: 849 revisions left to test after this
[88ca8ed0b7f2f04a055ff3c389f398ba3ad3d27d] V4L/DVB (4048): Add support for the Texas Instruments TLV320AIC23B audio codec
... （中略）
# git bisect good
Bisecting: 3 revisions left to test after this
[c22ce143d15eb288543fe9873e1c5ac1c01b69a1] x86: cache pollution aware __copy_from_user_ll()
# git bisect bad
Bisecting: 1 revisions left to test after this
[f2c780c1fdbe5008c902c2d7e37242ac5e60f0b9] Au1550/1200: add missing PSC #define's, make OSS driver use the proper ones
# git bisect good
Bisecting: 0 revisions left to test after this
[7dbdf43cfa635ddc3701cc8d1eab07597cd731c0] mips: fix number of mremap arguments
# git bisect good
c22ce143d15eb288543fe9873e1c5ac1c01b69a1 is first bad commit
commit c22ce143d15eb288543fe9873e1c5ac1c01b69a1
Author: Hiro Yoshioka 

Date:   Fri Jun 23 02:04:16 2006 -0700

    [PATCH] x86: cache pollution aware __copy_from_user_ll()

    Use the x86 cache-bypassing copy instructions for copy_from_user().

...
    Signed-off-by: Hiro Yoshioka 

    Signed-off-by: Andrew Morton 

    Signed-off-by: Linus Torvalds 


:040000 040000 73b282577d95f4b69f046f715ac6a5a4694ba758 a2b88cac24b674c0519352c3f74a122ed6e46e7a M      arch
:040000 040000 e15615138743db3d63ba41ca2c0cf00854e601eb e1d7a032e27ab3cb0bbe6df743d1ae644bd8a999 M      include
:040000 040000 8361e3dcee117b08ccce5ccc9d451d84b07edfad 847b80b43154037f25781dda0e059df7e94c1ff8 M      mm

ふんぎゃーー。わたしのパッチで何か問題があるらしい。
という感じになる。

今回このブログを書くきっかけは、下記のスレッドにある問題。2.6.18にしたらなぜかファイルがcorruptionした。
http://marc.info/?t=119116762100001&r=1&w=2

上記のようにbisectしてみたら、どうもcache pollution aware patchがなにやらやっているらしい。
http://marc.info/?l=linux-kernel&m=119135926624999&w=2

gitのログでわたしのメールアドレスが明記されているので、メールをCCされてしまって気がついた。

それにしても3399もあるコミットからいとも簡単に問題となるパッチを特定しちゃうんだからgitというツールはすごい。

さらに言うとLinusは何千もあるパッチのうち、当該パッチはmovntiを利用していて、キャッシュをバイパスしてデータをストアしているということを正確に理解している。

http://marc.info/?l=linux-kernel&m=119144213218621&w=2
http://marc.info/?l=linux-kernel&m=119146929402139&w=2

Linusってやっぱり神だよ。

git bisectのマニュアル
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

Git を使ってソース・コードを管理する
http://www-06.ibm.com/jp/developerworks/linux/060809/j_l-git.shtml

Real-life kernel debugging scenario
http://kernel.org/pub/software/scm/git/docs/v1.3.3/howto/isolate-bugs-with-bisect.txt

Bisection searches/みたのブログ
http://blog.miraclelinux.com/mita/2006/06/bisection_searc.html

プロのプログラマ

プログラマという職業。プログラムを作って給与を得る。が、定義かと思うけど、オープンソースを趣味で作っていてそれで所得を得ていない人は、じゃあ、プロのプログラマと言えないのか。

日本のIT産業のしょぼさは、ソフトウェア開発を人月単価でやりとりするところにあるというのが多くの人の指摘するところである。SIベンダーのエライ人が、学生の「大学では何を勉強すればいいですか」という質問に対して、「弊社では教育システムが完備していますから、大丈夫です」というような頓珍漢な答えをする。大学での専門的な勉強を期待しないということは、単に人を頭数で見ていることに他ならない。

「求人、プログラマ、未経験」を試しにぐーぐるしてみるとぞろぞろある。（求人　プログラマ　未経験 の検索結果 約 1,160,000 件中 1 - 10 件目 (0.08 秒) ）

誰でもできることをやっているとしたら、それはもう単価勝負にならざるを得ない。自分の仕事がオフショアされちゃったよということになる。

それじゃあだめだろうという事である。

小説家募集、未経験者歓迎。

日本語を書けるからといって、小説が書けるとは限らない。ましてや英語の読み書きができない人が、今から英語を勉強して、英語で小説を書くということを職業としてできるかということである。そんなことがまかりとおっていていいのだろうか。

学校を卒業した瞬間は確かに未経験である。しかし仕事の場でいろいろ経験を積み技術的な幅を広げていく。そのようなキャリアパスの中にプログラマという職業はあるはづである。

オープンソースのおかげでその経験を仕事以外で積み重ねることができる。入ってきたときは未経験でも、オープンソースの世界でリスペクトされるには高度な専門性が必要である。日々研鑚である。それはもちろんプロのプログラマでも同じである。

プロのプログラマならその専門性に磨きをかけないといけない。そういう世界である。

21世紀のプログラムは君たちが作る

U-20(Under 20)プログラミング・コンテストの入賞者向けのまつもとゆきひろさん、g新部さんの講演会とその後のワークショップ、そして授賞式に参加した。 

ワークショップでは、受賞者の皆さんと審査員との間での質疑応答があった。まつもとさんやg新部さんはどう考えても、ふつーのプログラマではないので、若いプログラマがすぐに彼らになれるかというとなかなかそうはいかないが、それでも、野球少年とイチローや松井との対話みたいな感じにはなると思う。

若手プログラマにとっての「まつもとゆきひろ」的なロールモデルは絶対必要である。この手のワークショップはなかなかスケールしない、すなわち規模の拡大は難しいが、それでも、若い人たちに語り続けることは重要である。

IT産業を３K産業などと揶揄するむきもあるが、仮にそのような状態があるとしたら、そのような状態を作っている企業人の責任は重い。若者に希望を与えるような産業構造にする義務が我々企業人にはある。その道は遠いが一人の企業人として、自社の仕事環境から少しでも理想に近づけることをし続けなければならない。

授賞式のあとの懇親会では甘利経済産業大臣も参加してU-20の皆さんと懇談していた。

まあ、それはともかく、若い人たちとの会話は凄く楽しかった。

21世紀のプログラムは君たちが作る。活躍を期待している。

21世紀のプログラムは君たちが作る/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/21_4f64.html

U-20プログラミング・コンテスト/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/u20_927d.html

U-20プログラミング・コンテスト公式ページ
http://www.jipdec.jp/procon/

（別紙２）平成１９年度 Ｕ－２０プログラミング・コンテスト入選作品の表彰(PDF形式
http://www.meti.go.jp/press/20070914003/20070914003.html

なお、平成19年度情報化月間情報化促進貢献個人表彰、経済産業大臣表彰「情報化促進部門」をまつもとゆきひろさんが受賞している。おめでとうございます。
http://www.meti.go.jp/press/20070914003/01_bessi01.pdf

10月5日追記："21世紀のプログラムを作る君たち"に伝えたかったことhttp://itpro.nikkeibp.co.jp/article/COLUMN/20071003/283741/　日経ITPro高橋さんが素敵な記事を書いてくれた。「ネットの向こうにいる仲間を信じよう。」

Intelのマニュアルを読む

Intel 64 and IA-32 Architectures Software Developer's Manuals　は下記にある。
http://www.intel.com/products/processor/manuals/index.htm

どれから読んだらいいか、よく分からないということであれば、 Volume 1: Basic Architectureをざっと見て、 Volume 3A: System Programming Guideに行くというのがオーソドックスかと思う。インストラクションセットの解説（ Volume 2A/2B）は辞書的に必要な命令について適宜参照するという形になる。

マイクロアーキテクチャについてざっくり知りたい場合は、Intel 64 and IA-32 Architectures Optimization Reference Manualの第2章がコンパクトにまとまっている。

最近のCoreマイクロアーキテクチャやPentium 4やXeonのNetBurstマイクロアーキテクチャについて紹介されている。

Coreマイクロアーキテクチャのところを読むと、In Orderのフロントエンドが4つの命令デコーダが、命令をμOPに変換し、Out of Orderの実行コアに送り、サイクル当たり6個のμOPを実行し、In OrderリタイアメントユニットがμOPの実行結果をサイクル当たり4つプログラム順に変換する。なんてことが書いてある。

14段のパイプライン、3つのALUなどなど。

フロントエンドには、BPU(Branch Prediction Unit)、Instruction Fetch Unit、Instruction Queue、Instruction Decoder、Stack Pointer Tracker、Micro-fusionなどの機能がある。機械語をμOPにサイクル当たり4つ変換する。

実行コアはフロントエンドから供給されるμOPをOut of Orderで実行する。renamerによって、レジスタ名を大量にあるマイクロアーキテクチャの内部レジスタ名に変換する。（いくつ内部レジスタがあるかは記されていない）。Reorder buffer (ROB)はμOP実行結果を保持する。ROBは96個のエントリを持つ。Reservation Station (RS)はμOPのすべてのソースオペランドがそろうまでキューに並べスケジュールする。RSは32個のエントリを持つ。

実行コアがサイクル当たり最大6個のμOPを同時に実行するというようなことが書いてある。その他メモリアクセスをどのように高速化しているかなど興味深いお話満載である。ぜひ原文にあたって欲しい。

Asianux Road Show、まつもとゆきひろさんの講演

Asianux Server 3の出荷を記念して、Asianux Road Showを東京、大阪、福岡で開催する。東京では、Rubyのまつもとさんにご講演をいただく。

なにやら、無理矢理お願いしちゃった感じで恐縮である。

まつもとさんの講演以外にも、わたしも僭越ながらちょびっと登場するし、豪華景品（ものでつるのかよ）があたる、抽選会もあるので奮って参加いただきたい。

エンジニアのためのテクニカルセミナー
2007年10月16日(火)　東京
2007年10月24日(水)　大阪
2007年10月31日(水)　福岡

正直言って、大阪、福岡の集客がまだまだなので、大阪、福岡在住の方は、ぜひご参加いただき、わたしと握手だ。（なお、まつもとさんのご講演は東京のみですので、そこんところはよろしく）

Asianux Road Show
http://www.miraclelinux.com/corp/event_seminar/2007/1016_1031_1.html
Asianux Road Show/東京のご案内。
http://www.miraclelinux.com/corp/event_seminar/2007/1016_1.html

ん？

8月13日より毎日土日も休まず本ブログを書いてきた。下記がこの一月半分のエントリーである。

弊社の他のブログ(ペンギン飼育係が見た、アジアのペンギン、第三のペンギン)はグループで書いているので、話題のバラエティが豊富で結果として新規のお客さんが多い。

一人で書いているとどうしても話題の幅が限られてしまうので、毎日毎日書き続けることと、もう一つしばりを自分に課した。下記のエントリをざっと見ていただけくと、それが何かわかるだろうか(50行後に種あかしする)。

8/13 Asianux Server 3
8/14 イノベーションのジレンマ
8/15 ウィキノミクス
8/16 NHKドラマ「ハゲタカ」
8/17 お休み
8/18 カーネル読書会のおしらせ(第79回)
8/19 北鎌倉
8/20 grubでのエラー
8/21 減量
8/22 コインロッカー・ベイビーズ
8/23 再放送：「ハゲタカ」
8/24 シリコンバレーの思い出
8/25 Suica
8/26 世界陸上
8/27 ソースコードの読み方
8/28 闘うプログラマ
8/29 チューニング
8/30 ツッコミ力
8/31 デバッグ方法論
9/01 図書館
9/02 ナニーニ
9/03 21世紀のプログラムは君たちが作る
9/04 ぬこ
9/05 ネタ切れ
9/06 ノルマ
9/07 ハッカー倫理
9/08 ビル・ゲイツの手紙
9/09 フリーソフトウェアの価値観
9/10 ベストセラーは読まない
9/11 北東アジアOSS推進フォーラム
9/12 Matzとひろゆき
9/13 mixiのスケーラビリティ
9/14 ムリ、ムダ、ムラ
9/15 メモリアクセスは遅い
9/16 Model View Controller
9/17 山勘で分岐先を実行することを投機的実行と呼ぶ
9/18 U-20プログラミング・コンテスト
9/19 よしおか賞とAsianux Server 3出荷記念
9/20 Lightning Talks
9/21 Richard Stallman
9/22 類型化
9/23 Latencyの隠蔽
9/24 ロックのいろは
9/25 wired society
9/26 ヲタクとハッカー
9/27 ん？

ページビューを増すために、土日を含めて毎日更新と、バラエティを増すために(話題が偏りすぎないように)、タイトルをあいうえお順にするしばりを自らに課した(なーんだ)。

そーやって記したエントリについてちょっと分析めいたことをしてみる。

46本のエントリのうち28本にはてなブックマークがついた。

人気のトップ5は
8/27 ソースコードの読み方
8/31 デバッグ方法論
9/15 メモリアクセスは遅い
8/24 シリコンバレーの思い出
9/07 ハッカー倫理

特に「ソースコードの読み方」は500を越えるブックマークがつき、この方面の興味が高いことがうかがえる。

8/28 闘うプログラマ
9/17 山勘で分岐先を実行することを投機的実行と呼ぶ
9/23 Latencyの隠蔽
なども2桁ぶブックマークがついた人気だった。

またプログラミングネタやbinary hack系（「メモリアクセスは遅い」、「山勘で分岐先を実行することを投機的実行と呼ぶ」、「Latencyの隠蔽」、「ロックのいろは」）が根強い人気があった。

あと、「ハッカー倫理」にまつわるお話も人気だった。（「フリーソフトウェアの価値観」、「Richard Stallman」など）

ネタ切れで息切れ感がただよったのが、「ネタ切れ」である。短いエントリは無理矢理書いているものが少なくない。

あいうえお順という縛りがあったのでタイトルに無理があるのも少なくない。ノートに50音表を書いて全体像をあらかじめ描いていたのであるが、ところどころ空白のところがあって、そこを埋めるのが厳しかった。「ぬこ」は「ぬ」ではじまる話題が他に思いつかなかったのが正直なところである。

一方で同じ音でも書きたい事が複数あるのもあった。「Richard Stallman」にするかLinus Torvaldsにするかとか。

よしおかひろたかの「50音ブログ」であったわけであるが、ブックマークもいっぱいついたし、毎日まがりなりにも書き続けることができたわけだし、自分としても、締切におわれる漫画家(？)みたいな感覚を得られたし、なかなか面白い経験であった。

ブログというのは自分のために書いているのだから、自分が楽しめなければいけない。そのために何らかのお題を自分に出して、それをこなしていくというのも意外と楽しい。昔のブログを眺めながらそれをネタにするというのも、自分が気がついていない再発見が結構あって勉強になった。

そんなこんなで、本日、「ん？」でこの実験は一区切りとしたい。

ヲタクとハッカー

時々思うのだが、インテルのマニュアルを意味もなく見ている自分というのは、そーとーやばいと思う。別にインテルのマニュアルを隅から隅まで読んだところで会社の経営にプラスになる何かあるわけではなく仕事に直接関わっているというわけでもないので、趣味といえば趣味であるし、それによって経済的なメリットがあるとか人生が幸せになるとか異性にもてるとかそーゆー事は一切ない。

先日テレビを見ていたら換気扇ヲタクという換気扇の美に魅せられた人たちが出ていた。換気扇を見るといてもたってもいられない性格らしい。まあ、世の中にはいろいろな人がいるわけで人に迷惑をかけていなければとやかく言われる筋合いのものでもない。

インテルのマニュアルを繰り返し読んでいるとコンピュータアーキテクチャの実装上の様々なお話が出てきて勉強になって、いつの日か仕事の役にたつのではないかというスケベ心もなくはないがここ数年インテルのマニュアルが仕事で役にたったというのは数年前未踏ソフトウェアプロジェクトでのhardmeterの実装のときと、このブログでも再三とりあげているCache Pollution Aware Patchを実装したとき位だから、やっぱり趣味の範囲を超えないような気がする。

むしろ、ヘネパタがどーだとかコンピュータアーキテクチャの薀蓄を語るときの貴重なネタ本としての活用の機会のほうが圧倒的に多い。ブログでのネタの提供もとでもある。

はっきり言ってIA-32 Architecture Reference Manual Vol 3については穴の開くほど繰り返し読んで、おそらく私以上にこのマニュアルを読んだ人は日本にはそうはいないだろうという実感はあるのだが、（本当かいな？単に自分が知らないだけだとは思うけど）、カーネル読書会みたいに、そーゆーことを嬉々として語れる場があるというのは、幸せなことかと思う。

ヲタク倫理というのがあるのかないのかは知らないが、どーでもいいことにとことん拘ってそれを極めるというのは日本のヲタクの道みたいな気がするけど、それとハッカーの気質というのはかなり共通点があるような気がする。

シリコンバレーはハッカーと資本主義が微妙なバランスの上で成り立っている世界でもまれな地域かもしれないが（過度な類型化に注意しないといけないと自戒しつつ）、一方で東京だって、どうしてどうしてヲタクが様々な価値を作りつつあるのではないかななどと思ったりするのである。

ニコニコ動画RCが大人気であるが、ぱっとみ、YouTubeのパクリかよと思うけど大間違いで、Flashのハッカーが作った、2chの動画版というコンセプトはYouTubeとはまるで違った地平線を開拓した。

日本のエスタブリッシュメントは2chを決して理解しようとしないし分かるつもりもないと思うが、それと同様にニコニコ動画RCのインパクトを理解しようとしないと思う。（閑話休題）

ニコニコ動画RCはヲタクが社会にインパクトを与えたという例だと思う。その意味でヲタク魂はハッカーと共通のものを持ったような気がする。

日本という地域がナード（コンピュータヲタクというような感じの人たち）の価値を理解しないという梅田望夫の指摘は90年代はそうだったかもしれないが、21世紀になって微妙に変化しつつあるのではないかという予感がしている。（というようなことを言うとまた梅田に怒られちゃうのではあるが、だけどあえて書く。）

シリコンバレーの思い出/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/08/post_dd7a.html

シリコンバレー精神/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/08/post_a196.html

フリーソフトウェアの価値観/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_0866.html

wired society

3連休でブログネタも尽きたことだしなにを書くかなどと考えていて、趣味のインテルのマニュアルを読んでいたところ、割り込みと例外の章（Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1）をたまたまめくっていたのでそれについて書こうかなと思ったのだが、急に気が変わる。

昔ウェブ人間論を読んだ時に書いた感想をたまたま読んで、ああ、インターネットは人々と結線(wired)したのだなあなどと再確認した。http://blog.miraclelinux.com/yume/2006/12/post_2666.html

Wiredという雑誌があったけど（今もあるのかな？）、日本語版も出ていたがいつのまにかになくなってしまった、インターネットは我々を結線したというのが非常にインパクトがある概念だった。

世界がインターネットで繋がっている。

すげーぞ、それはというワクワク感であった。

ハッカーがなぜプログラムを書くかという問いかけに私自身まだ明確な回答は持たない。持たないが、自らの自由意志でプログラムを書く多くのハッカーを知っている。給与を貰うプロのハッカーから100％自由意志で誰からも拘束されないでコードを書くハッカーまで様々な人たちがいることを私は知っている。

なぜハッカーはプログラムを書くのか。

21世紀の謎である。しかし、インターネットのおかげで彼らはインターネットに結集した。インターネットは彼らを結線した。

それによってとてつもない価値の再生産が始まった。

結線された社会はそうでない社会よりも幸せなのか。ハッカーはその社会にどのような役割を演じるのか。

疑問はつきない。









下記はボツにした原稿。もったいないのでそのうち使うかもしれない。

割り込みは現在実行中のプロセスとは独立に発生する。例外は現在のプロセスの実行によって引き起こされる。例えばゼロ除算とかページフォルトとかは例外である。

割り込みも例外も発生するとそれに対応したハンドラを起動し様々な処理を行なう。例外の場合、ゼロ除算とかは当該プロセスに通知して実行を終了するものから、ページフォルトのようにOSによって適切に処理されるものまで様々なものがある。

IA-32の場合は、おなじみの下記のマニュアルの第5章を参照のこと。

Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1
http://www.intel.com/products/processor/manuals/index.htm

リアルタイム系OSの場合、割り込み処理を一定時間で処理することを保証しなければいけないのでなかなか大変である。

ロックのいろは

ロックと言うのはプログラミング上のコンベンション、慣用句みたいなもので、共有資源へのアクセスに対する同期のメカニズムとして利用される。

ある共有資源を複数のプロセッサ（あるいはプロセスでもいいけど）から同時に利用したいとする。変数に１を加えるという単純な動作ですら同期をとらないと正しい結果を得られない。

ロックはそのような同期を必要とする場面でよく利用される。ロックを取得したただ一つのプロセスのみその共有資源にアクセスできるようにするのである。

アトミックに値をセットしてテストする命令(test and set)を利用しロックが取得できるまでひたすらループして待つ、いわゆるスピンロックという単純素朴な方法がある。IA-32だとxchgという命令があって、あるメモリとレジスタの値をアトミックに（他のプロセッサに邪魔されることなく）行うことができて、それを利用する。例えば、0がロックされていない状態、１がロックされている状態とすると、下記のコードがそれをナイーブに実装したものである。

Spin_Lock:
Get_Lock:
    MOV EAX, 1;
    XCHG EAX, lockvar; // Try to get lock.
   CMP EAX, 0; // Test if successful.
   JNE Spin_Lock;
//
Critical_Section:
   
   MOV lockvar, 0; // Release lock.

lockvarとEAXレジスタの値を交換して、lockvarの値が0であったら誰もロックを取得していないので下に行く。誰かがロックを取得していたら1が入っているので、Spin_Lockにジャンプして繰り返す。ロックを取得できたら、共有資源にアクセスするなりなんなりをして最後にlockvarに0を代入しロックを解放する。そうすると同じロックを取得するために待っていた誰かがロックを獲得できるようになる。

上記の実装は間違いではないのだけど、実装上性能に多くの問題がある。毎回、xchg命令でメインメモリにアクセスに行くのだがアトミック性を保証するため、つまり値を交換しているとき、他の誰かが別の値に交換しないようにバスをロックし、単一のプロセッサだけが当該メモリにアクセスできるようにする。そうするとxchg命令実行中は他のプロセッサはバスがロックされているのでメインメモリにアクセスできない。プロセッサの数が増えれば増えるほどバスの競合が発生しスケールしない。またメモリアクセスは遅いでも書いたが、メモリアクセスはキャッシュアクセスに比べ100倍は遅いので毎回毎回のたのた動き回ることになる。まあ、スピンロックで持っているわけだから別に他に仕事がないので遅くてもいいっちゃいいのだが、先のバスロックはいただけない。

でもって、通常はどうするかと言うと、もう少しリラックスした方法になる。
先の実装のSpin_LockとGet_Lockの間に下記のコードを埋める。何をしているかというと、cmp命令でlockvarが0かどうか最初にチェックしている。つまり、ロックされているかチェックして、仮にロックされていなかったら、Get_Lockにジャンプしてロックの確保を試みる。

Spin_Lock:
   CMP lockvar, 0 ; // Check if lock is free.
   JE Get_lock
   PAUSE; // Short delay.
   JMP Spin_Lock;
Get_Lock:

cmp命令を実行してから、次のxchg命令まではアトミックではないので、他のプロセッサがその間にロックを取得してしまう可能性があるので、xchg命令で再度ロックが確保できるか確認している。cmp命令でlockvarを確認するのは、それがキャッシュに載っていればキャッシュアクセスなので高速に判定できる。ロックが取得できないときのループもキャッシュへのアクセスを延々と続けるので、メインメモリにアクセスしないので、他のプロセッサの邪魔をしないためスケーラビリティがある。メインメモリへのアクセスは他のプロセッサとの調停が必要なのでプロセッサの数が増えれば増えるほどコストが増大するので、できれば避けたいのある。

またスピンループ中にpause命令を入れているがこれはnopで、プロセッサに対しフルスピードでループしているけど他に有益な仕事があるんだったらそれを先にやってもいいよ、あるいは消費電力を落としてもいいよ、みたいなヒントになっている。IA-32の慣用句である。（蛇足）

スピンロックを実装するときに上記のように二重ループにするのはロックのいろはなのであるが、ユーザーランドで実装するときも注意したい。

また上記のようなアプローチはTest and Test-and-setとしても知られている。

上記の例はIntel 64 and IA-32 Architectures Optimization Reference Manualの8.4.2からの引用である。http://www.intel.com/products/processor/manuals/index.htm

メモリアクセスは遅い/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_b3bc.html