アトミックな操作 について

kernel

_不可分操作_とある。若干微妙な部分があり、停滞気味。ひっカカッてる部分を明らかにする意味も込めてエントリを投入。
リエントラントな状態を保つための要件を満足する (競合状態を防ぐ) 方法として、複数のコンテキストがアクセスできるグローバルなモノに対する操作を_CPU レベルでひとつの命令で実行されることを保証する (amazon:詳解 Linux カーネルより引用)_ 命令が用意されている、との事。
amazon:詳解Linuxカーネルによれば intel 80x86 な命令に関する所見は以下、との事。

  • 一回のメモリアクセス、もしくは全くメモリアクセスを行なわないアセンブリ命令はアトミック (amazon:詳解 Linuxカーネルより引用)
    これはなんとなくイメージできる。intel なマニュアルではもう少し色々と記述があったんですがとりあえず略。
  • inc や dec はアトミックであると保証できかねる。
    _できかねる_条件が微妙。基本的に UP ではアトミックと判断して良いのだろうか。(一応、_他のプロセッサにメモリバスを奪い取られなければ (amazon:詳解 Linuxカーネルより引用)_とあるな)
  • lock プレフィクスされている命令はプロセッサが複数でもアトミック。
    lock プレフィクスにより命令の実行が終わるまでメモリバスを「ロック」(amazon:詳解 Linux カーネルより引用) するとの事。
  • rep プレフィクスな命令はアトミックではない
    これは理解可能。普通に考えてアトミックだとマズいっしょ。(類推)

amazon:詳解Linuxカーネルには_アトミック操作、な一覧_があるが、先日覗き見た atomic_inc() なナニを見てみた。

include/asm-i386/atomic.h

static __inline__ void atomic_inc(atomic_t *v)
{
	__asm__ __volatile__(
		LOCK "incl %0"
		:"=m" (v->counter)
		:"m" (v->counter));
}

LOCK はこのヘッダ上部で #define されておる。(TAG を引っ張ったら違うヘッダに飛んだんですが、これは何故でしょうか。って多分 TAG の作り方が駄目なんだろな)

#ifdef CONFIG_SMP
#define LOCK "lock ; "
#else
#define LOCK ""
#endif

SMP ではない環境では、LOCK プレフィクスは付いてない。atomic_inc なインライン関数を眺めた瞬間、あるいは UP な環境で LOCK プレフィクスが付かねぇんだ、という事を認識した瞬間、これはもしかすると UP な環境ではアトミックな操作ではあり得ないのかもしれない、という疑念が頭の中でばんばん大きくなってしまっていたんですが (馬鹿)、inc や dec が保証できかねる、という部分の理解が正しければ (類推ベースなんですが) incl な命令途中で割り込み発生、な事象は発生しないに違いないのだろうな、と。intel のマニュアルの読み込み方が足らんかなぁ。
ちなみに_アトミック_な記述は 3 巻のマルチプロセッサ管理な部分にしかない。アトミックな操作がキモ (必要) になるのは SMP なナニ限定と見て良いのかなぁ。<蛇足>
もしかすると、atomic_t 型にもアトミックな所以があるかも。あるのか。

include/asm-i386/atomic.h

typedef struct { volatile int counter; } atomic_t;

これって、普通の int な変数を atomic_t でキャストしたら volatile な変数として扱ってくれるのかなぁ。都合良スギな気がするんですが。

追記

ちょっと微妙な表現を修正。