Memory Barrier

asm volatile("":::"memory")

compiler-gcc.h 파일을 보면 barrier()는 다음과 같이 구현되어 있습니다.

#define barrier() asm volatile("": : :"memory")

특별히 어떤 명령어를 수행하는 것은 아닙니다.
보통 리눅스 커널에서는 barrier() 매크로를 이용하는데, 이것이 위와 같이 asm volatile("":::"memory")로 정의되어 있습니다.
보통 이것을 우리는 "컴파일러 barrier" 또는 "Software barrier" 라고 부릅니다.
이 barrier 는 CPU instruction 을 수행하는 것이 아니기 때문에, CPU 의 경우는 이 barrier 를 인식하지 못합니다.
단지, 컴파일 단계에서 컴파일러만 이 존재를 알고 그 역할을 수행합니다.
코드 상에서 이러한 컴파일러 barrier 를 만나면, 컴파일러는 최적화 수행 시에 이 barrier 경계를 넘어서 메모리에 대한 접근연산(Load/Store)들을 재배치(Reordering)하지 못합니다. 즉, barrier 를 기준으로 윗쪽의 load/store 연산을 barrier 아랫쪽으로 이동하거나 하는 최적화를 수행할 수 없습니다.
하지만, 이러한 barrier 는 당연히 barrier 경계만 넘나들지 않으면 그 양쪽에서 재배치하는 것은 막을 수 없습니다. 그리고, 위에서도 언급했지만 CPU 의 경우는 이 barrier 의 존재를 모르기 때문에 하드웨어의 동작에는 어떤 영향도 주지 않습니다.
즉, 하드웨어적인 barrier 의 역할은 절대 수행할 수 없습니다.

__sync_synchronize()

반면에 __sync_synchronize 는 컴파일러에서 제공하는 builtin atomic 함수입니다. 아래와 같이 gcc 에 내부적으로 inline 으로 구현되어 있습니다.

void 
__sync_synchronize (void) 
{ 
#if defined(arm revisions supporting dmb) 
  asm volatile("dmb" : : : "memory"); 
#else 
  asm volatile("" : : : "memory"); 
#endif 
}

dmb 라는 명령어가 보이는군요. 이는 ARM 아키텍쳐에서 제공하는 메모리 barrier 를 위한 CPU instruction 입니다. dmb 명령어를 지원한다면 이를 사용하고, 지원하지 않으면 위에서 본 것과 같은 그냥 컴파일러 barrier 로 동작하는군요. (x86 의 경우는 mfence, sfence 로 구현되어 있습니다.)
dmb 명령어는 별도로 살펴보겠지만, Load/Store 연산의 결과(즉, 데이터 Access 결과)가 dmb 가 끝날 때까지는 같은 공유도메인의 다른 Agent 들에게 Visible 함을 보장하는 것입니다. 한마디로, 내가 메모리 변경작업을 한 후 dmb 명령을 수행하면, 나와 같은 공유도메인에 묶인 놈들에게는 그 결과가 dmb 의 완료 시점을 기준으로 보여야 한다는 것입니다. 그래야만, 여러놈이 공유 데이터 영역을 정확하게 관리할 수 있겠죠.

결국, __sync_synchronize 는 내부적으로 하드웨어까지 영향을 미치는 Memory barrier 명령(Hardware barrier)을 사용하도록 감싸놓은 builtin 함수에 불과한 것이네요.
참고로, 이러한 하드웨어 barrier (dmb, dsb, isb)를 사용하면 컴파일러 barrier 의 역할까지 포함됩니다.

gcc 에서는 __sync_synchronize 외에 __sync_fetch_and_add, __sync_val_compare_and_swap 등의 builtin 함수들을 제공합니다. (gcc builtin 함수)
이러한 builtin 함수들은 결국 아마도 모두 내부적으로 atomic 또는 barrier 의 역할을 수행할 수 있도록 ldrex, strex, dmb, dsb 등의 명령어를 사용하는 inline assembly 코드로 구현되어 있을 것이라는 것을 쉽게 짐작할 수 있습니다.