네.. 그렇군요.. 어느 김태훈님인지 모르겠지만, 잘 생긴 김태훈님이라 생각 됩니다. ^^
// include/asm-x86_64/system.h

#ifdef CONFIG_SMP
#define smp_mb() mb()
#define smp_rmb() rmb()
#define smp_wmb() wmb()
#define smp_read_barrier_depends() do {} while(0)
#else
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
#define smp_read_barrier_depends() do {} while(0)
#endif

/include/asm-arm/system.h

#ifndef CONFIG_SMP
#define mb() do { if (arch_is_coherent()) dmb(); else barrier(); } while (0)
#define rmb() do { if (arch_is_coherent()) dmb(); else barrier(); } while (0)
#define wmb() do { if (arch_is_coherent()) dmb(); else barrier(); } while (0)
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
#else
#define mb() dmb()
#define rmb() dmb()
#define wmb() dmb()
#define smp_mb() dmb()
#define smp_rmb() dmb()
#define smp_wmb() dmb()
#endif

암은 다 dmb 를 호출하도록 되어 있더군요.. 참 그리고, 한가지 궁금한 점이 있는데..
컴파일러 최적화에서 volatile 키워드를 사용하는 것이랑 barrier 사용하는 것이랑 다른점은 무엇입니까?

몇년 지나면 암은 정복된다고 하더군요. 그래서 요즘 암 보험 드는 사람이 줄어 들지요.. ^^

volatile 키워드는 volatile 키워드로 지정된 주소 공간에 대해서 read operation이 발생할때 마다 매번 주소 공간에서 read 합니다.
보통 gcc는 최적화 과정에서 어떤 변수 또는 주소 공간에 대해서 이전에 그 주소 공간의 값을 레지스터로 읽어 왔고,
프로세서가 명시적으로 해당 변수의 값을 변경하지 않았다면 다시 주소 공간에서 읽어오지 않고 레지스터에 읽어온 값을 사용하게 되어 있습니다.

예를들면 r1이 callee saved register라고 가정할때

volatile int mem;
a = mem;
delay();
a = mem;
a = a + 1;

같은 경우에는

r1 <= *(mem)
call delay
r1 <= *(mem)
r1 <= r1 + 1

이렇게 코드가 생성되는가 반해

int mem;
a = mem;
delay();
a = mem;
a = a + 1;

같은 경우에는

r1 <= *(mem)
call delay
r1 <= r1 + 1

이렇게 코드가 생성됩니다. 보면 volatile로 지정된 mem 변수는 read operation이 발생할때마다 매번 값을 읽어온 반면 volatile로 지정되지 않은 mem 변수는 최초 한번만 읽어오는것을 확인할수 있을겁니다.

메모리 operation은 다른 operation 보다 많은 사이클이 들기 때문에 이렇게 하면 보다 사이클을 줄일수 있습니다.

하지만 memory mapped된 장치의 레지스터 같은 경우 프로세서가 명시적으로 write하지 않았다 하더라도 값이 장치에 의해 변경되게 됩니다.
이럴경우 volatile 키워드를 붙여주어야만 해당 주소 공간의 값을 매번 읽어와서 의도된 대로 동작하게 할수 있습니다.


barrier() 같은 경우에 다음과 같은 매크로로 define 되어 있습니다.

#define barrier() __asm__ __volatile__("": : :"memory")

보면 아무른 operation도 없는 inline assembly 코드입니다. 콜론(':')으로 구분된 "memory" 표기되어 있는 세번째 필드는 clobber 필드라고해서 해당 inline assembly가 수행된후 값이 변경되는 것들을 기입합니다.
gcc는 clobber 필드에 기입된 내용을 토대로 다음 코드를 생성하면서 최적화를 수행하는데 일반적으로 값이 변경된 것들에 대해서는 어떤 값으로 변경된지에 대한 정보가 없기 때문에 최적화를 수행할 수 없습니다.

clobber 필드에 "memory"라고 표기 하는것은 모든 메모리 타입 저장 장치(모든 레지스터, 모든 프래그, 모든 메모리 등)의 값이 변경됨을 의미합니다.
gcc는 이럴경우 __asm__ __volatile__("": : :"memory") 경계를 넘어가는 최적화 또는 instruction scheduling을 수행하지 않습니다.
때문에 __asm__ __volatile__("": : :"memory")를 사용하면 이전 코드의 수행 완료를 보장할수 있고 이후 코드가 __asm__ __volatile__("": : :"memory") 이전에 수행되는것을 방지 할수 있습니다.

네 잘 알겠습니다. 차이가 명확하게 이해가 되는군요.
저희 암 스터디가 열심히 하고 있으니, 암을 정복 할 수 있을 것입니다. 걱정하지 마세요.. ^^

이전에 적다 말았는데, 암이 정복된다니 다행입니다. 제 생활 습관 때문에 걱정하고 있었는데 다행입니다. arm11 팀도 암을 정복하신다니 다행입니다. arm11 팀이 암을 정복하는거에 대해서는 전혀 걱정하지 않았답니다. =)

감사합니다~오호호호....
하드웨어 차원에서 instruction을 재정렬 한다는 것이 있는줄 몰랐습니다.

#if __LINUX_ARM_ARCH__ >= 7
#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
#elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
#define dmb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5"
: : "r" (0) : "memory")
#else
#define dmb() __asm__ __volatile__ ("" : : : "memory")
#endif

이백님이 올려주신것처럼 dmb명령이나 mcr p15, 0, %0, c7, c10, 5 명령이 있는것을 보니 하드웨어적으로 명령어를 재정렬해주는 기능이 있나 보네요. 이것을 방지하는게 이런 명령인것 같고 그리고 조건부 컴파일 상 v6이전 버전에는 하드웨어적인 재정렬이 없는것으로 추측할 수 있겠네요.

그럼 대체 하드웨어적인 재정렬은 어떻게 이루어질까요 물론 하드웨어 설계관점에서 접근해야 하겠지만 컴파일러가 재정렬하는것만큼의 수준의 재정렬을 수행하기는 어려워 보이는데...명령어를 읽어서 디코딩 하는 순간에 어떤 작업이 일어날 것 같은데 궁금하네용..

ftp://ftp.cs.wisc.edu/sohi/papers/1995/ieee-proc.superscalar.pdf

Memory Barrier.......

음...이게 예전에 AMP 기반의 two core를 할 때 봤던 적이 있는 것 같습니다.
결론적으로 이야기 하자면, Memory Barrier라는 것이 Memory의 Protectioin을 거는 것입니다. 일단 두 개의 프로세서가 하나의 메모리 영역에 접근한다고 했을 때, 접근시에 동기화가 필요합니다. 프로세서 A에서 값을 기록했다가 프로세서 B에서 값을 읽거나 할 경우에 프로텍션을 걸어줌으로써, 해당되는 프로세서가 값을 읽지 못하도록 만들 수 있습니다.

메모리를 관리해 주는 유닛은 MPU와 MCU가 있는데, 요즘은 MCU가 일반화 되어 있지만, 과거에는 MPU를 썼다고 합니다. Kernel 부팅에 대한 어셈블리에서 도메인에 대한 부분은 간단히 봤었는데, MCU에서 Memory Protection을 걸어줄 때, 도메인을 사용합니다. 자세한 내용은 ARM System Developer's Guide를 보시면 나와 있습니다..^.-

volatile 지시어도 Memory Barrier의 일종이라고 보실 수 있습니다.

ㅋ실시간 리플..^^

제 생각에는 Memory Barrier, 메모리 접근 동기화와 (MPU,MCU)는 셋이 좀 다른 문제인것 같습니다.

일단 Memory Barrier는 위에서 여러분들이 말씀하신 것처럼 컴파일러 최적화와 하드웨어 instruction 재정렬 관련문제를 의미한것 같구 메모리 접근 동기화와는 조금 다른 문제가 아닐까 싶은데요
메모리 접근 동기화라고 하면 또 소프트웨어적인것과 하드웨어적인 것으로 나눌수 있을것 같습니다. 소프트웨어적인것이라하면 일반적인 lock같은 류를 들 수 있을 것 같고 하드웨어적인 것이라면 말그대로 cpu간에 동시에 메모리를 접근할 수 없으므로 이에대한 어떤 메커니즘이라고 생각합니다. 또한 arm11이상의 아키텍쳐에서는 원자적인 메모리접근을 지원하는 하드웨어적 명령이 있는듯 하네요 다른아키텍쳐들도 지원되는걸로 알고 있습니다.

음..아직 잘 모르겠지만 SMP환경이라면 각각의 CPU간의 메모리 접근의 허가를 허락해주는 어떤 하드웨어적인 요소(?)가 있을거라고 생각하구요..AMP환경이라면 이것이 어떻게 이루어질지 궁금하군요...잘 모르지만..NUMA구조와도 관련이 있을 것 같고 아직 현대 OS에서 해결해야할 과제라고도 어디서 주워 들은 것 같은데..

마지막으로 MPU,MCU는 MPU(Memory protection unit)과 MCU혹은MMU(virtual memory+MPU)정도로 보시면 될거 같습니다.

앗..그리구 위의 자료 감솨감솨~~^^...

저도 언젠간 언어의 장벽을 극복할 수 있는 날이 오리라 굳게 믿습니다...

Kernel Document의 memory-barriers.txt 파일 참조하세요.. :-)
궁극적으로는 이백님이 말씀하신 용도로 사용하는 것이 맞는 것 같습니다.
허나 접근하시는 방법이 너무 어려워서 잘 이해가 안 가서 조금 찾아봤습니다.... :-)