介紹一篇LWN的文章[1]，該文整理了atomic API的幾個使用時機，以及不建議的場合： https://lwn.net/Articles/698315/ 1. Simple flag ( 設後不理 ) NFS RFC實作原本有很多的flag透過bit field表示狀態： unsigned int sl_temp : 1; /* temp socket */ 由於bit field的更新會造成同一個word的read-modify-write，所以原本作法是透過spin_lock來避免 在SMP下的race condition。但是spin_lock在這個情況下有點太肥，因為會限制其他field的同時存取， 後來改用set_bit()/clear_bit()，由硬體支援的atomic 指令來完成。 （EX: arch/arm64/lib/bitops.S） 所以：如果 只有 bit fields 要更新，可考慮atomic API ，避免不必要的lock 。 2. Counters 很多kernel的統計資料會透過per-cpu counter逐次累加，需要獲取時才再加總。但是對於不是太常 更新的counter，可以透過一個global counter，然後使用atomic_add()來簡化設計 (EX:許多file system的logging stat)。 所以： per-cpu counter ，可考慮改為單一global counter 。 3. Exclusive ownership （設後要理） #1只對flag作update，設後不理。但是如果flag是拿來當作互斥使用時，就要再考慮barrier的問題， 並使用對應的版本： if (!test_and_set_bit_ lock (BIT_NUM, &bitmap)) { ...