這是之前我在面試的時候遇到的奇怪問題，當時回答的不好，只回答了
「這個是避免編譯器幫你省讀取，但是不保證多輕量行程的同時存取同步」
要我舉例什麼時候有用到，我雖然指出有的時候類似poll()或者loop的時候
會用來保護某些用來存hardware讀上來的flag，但是現代編譯器會很避免這種問題了。
我這些年在linux kernel中是很少看見了，因爲io remap的記憶體位置是non cache的，
非要涉及與cache有關係的，我好像更常用RW barrier。
現在才看到這篇文章，原來在Linux kernel是看不到使用volatile的了
https://lwn.net/Articles/233479/
雖然後來無事入職了，但是我個人對這種很吃編譯環境的題目很感冒，覺得什麼
年代的問題都會拿出來問(這位面試官還問了類似問題)，我又不好給出完全否定的
答案，萬一面試官不知道這樣的變更怎麼辦。
我後來查驗了Gstreamer的代碼，除了那些使用asm或者orc的代碼外，好像都沒有
看見在用volatile了。應該現代GCC和CLANG都是可以正確應對這部分問題了。
而對於MCU來講，Keli C或者IAR C這些編譯器倒是會根據volatile作出蠻奇怪的
反映的。很多MCU platform上對registers的存取都是通過一個C variable進行的，
有這樣的行爲倒是一點都不奇怪。而某些使用GCC的可能也會被過度優化，造成
沒有進行改有讀取作業。文章中有特別註明這裏和kernel中的不同：
『But, within the kernel, I/O memory accesses are always done through
accessor functions; accessing I/O memory directly through pointers
is frowned upon and does not work on all architectures.』
個人倒是不清楚DSP用C compiler會不會有這種問題。

volatile用多了效能會很傷嗎？

那atomic呢？

我覺得文章裡的 accessor function 指的是 readb / writeb這類也要用 pointer 來讀寫的，devm_ioremap_resource (ioremap?) 沒有去讀，應該不算？devm_ioremap_resource 傳回來的是 __iomem*，剛剛找了幾個地方，在用傳回來的 __iomem* 去做讀寫 (dereference) 的時候，都有透過 readb / writeb 之類的 function/ macro。不太清楚你的觀點是？

用到的場景：在MCU裡前景程式要檢查背景中斷更改過的變數值；或是程式碼直接讀取硬體暫存器值。這時 volatile 好用，其他時候都用不到