volatile에 대한 오해

“임베디드 프로그래밍 C 코드 최적화” 라는 책을 살짝 보는데 다음 내용에 오류가 있다. 아무리 이 책이 임베디드 환경을 기본으로 했다 하더라도 혼동하기 쉬운 내용이다. 53, 54, 57페이지의 내용이다. 책 내용 일부를 무단 전제하는 것이라 저작권에 위배되는 것 같지만 그래도 좋은 일(?) 하기에 양해 좀 부탁 드립니다.

1: // 하드웨어가 사용하는 메모리는 volatile로 선언2: #define TEMP (*(volatile unsigned int *) 0x001)3: void main(void) {4: int a[10], i;5: volatile int j; // 지연 루프에서 사용하는 변수를 volatile로 선언하여6: // 컴파일러가 최적화시 코드 제거를 막을 수 있도록 함.7: TEMP = 0x0;8: for(i = 0; i < 10; i++) {9: a[i] = TEMP;10: for(j = 0; j < 100000; j++);11: }12: for(i = 0; i < 10; i++)13: printf("a[%d] = %d \t", i, a[i]);14: }
volatile의 기능적 의미는 캐시사용안함(no-cache)이다. 보통 프로그램이 실행될 때 속도를 위해 필요한 데이터를 메모리에서 직접 읽어오지 않고 캐시(cache)로부터 읽어온다. 하지만, 하드웨어에 의해서 변경되는 값들은 캐시에 즉각적으로 반영되지 않으므로 데이터를 캐시로부터 읽어오지 말고 주 메모리에서 직접 읽어오도록 해야한다. 이러한 특성 때문에 하드웨어가 사용하는 메모리는 volatile로 선언해야 하드웨어에 의해 변경된 값들이 프로그램에 제대로 반영된다.

volatile은 임베디드 소프트웨어에서 자주 사용하는 타입 한정자이다. 하드웨어가 사용하는 메모리 선언 시에 주로 사용되고, 최적화 금지의 용도로도 쓰인다. 기본개념은 캐시사용금지(no-cache)로 변경된 값을 즉각 주 메모리에서 읽을 수 있게 하여 프로그램에서 하드웨어의 번화를 감지할 수 있도록 하는 것이다.

(볼드체는 내가 강조한 것임)

전형적으로 volatile에 대해 오해하고 있는 두 가지 사실이다. 일단 임베디드 환경 뿐만 아니라 보통 PC 같은 컴퓨터도 생각해보자.




C/C++가 정의하는 volatile 키워드는 이 값이 언제든지 변할 수 있기에 컴파일러는 최적화하지 말 것을 지시한다. 따라서 이 의미가 직접적으로 “캐시 사용 안 함”은 아니지만 간접적으로 이 말은 맞다. 그런데 여기서 말하는 캐시는 CPU 내의 L1/L2 캐시가 아니라, 레지스터를 가리킨다. 컴파일러는 보통 최적화를 할 때 최대한 변수가 레지스터에 머물도록 한다. 그러니까 변수를 레지스터에 ‘캐싱’하는 것이다 (추가: 레지스터에 캐시한다는 내용은 댓글을 봐주시면 고맙겠습니다. 보통 이런 경우, 레지스터에 캐시한다고 표현하지는 않지만, 반복적인 메모리 접근 대신 레지스터에 그 값을 두고 쓴다는 의미에서 캐시라는 표현을 썼습니다)

그런데 레지스터는 스레드마다 유효한 문맥(context)이므로 (다른 스레드에 유효한 레지스터 값을 쉽게 보는 방법은 없다) 다른 스레드가 이 변수 값을 수정한다면, 레지스터에 캐시된 값은 최신 값을 반영하지 못한다. 이런 문제를 막기 위해 volatile 키워드를 사용한다. 이 키워드는 컴파일러가 이런 레지스터에 캐시하는 것을 막으므로 항상 메모리에서 값을 읽도록 한다. 그런데 잠깐, 여기서 메모리는 정확하게 무엇을 가리키는가?

여기서 또 혼동하는 것이 volatile로 선언된 변수가 CPU 내의 캐시를 다 무시하고 바로 메모리(=DRAM 주메모리)에서 읽고 쓴다는 것이다. 캐시의 의미를 CPU 캐시로 오해했기 때문에 이런 이야기를 하게 된다.

일반적으로 이 말은 옳지 않다. 아무리 volatile을 붙인 변수라도 여전히 CPU 캐시를 활용한다. CPU의 캐시는 보통 사용자에게 투명(transparent)하므로 캐시가 있으나 없으나 밖에서는 구분하기 어렵다. 보통 특수한 명령어1)를 쓰지 않은 이상 데이터를 읽으면 CPU가 알아서 L1/L2 캐시에 있으면 거기서 값을 주고 없으면 DRAM까지 갔다 온 뒤 값을 돌려준다. 물론 세밀한 성능을 위해 캐시를 제어할 수 있는 명령도 제공된다.

그런데 예외가 있다. x86 CPU에는 특정 메모리 주소 영역을 캐시 가능하지 않도록 설정할 수 있다. MTTRs(Memory Type Range Registers)과 PAT(Page Attribute Table)라는 기능으로 캐시 가능한 부분과 그러하지 않은 부분을 제어할 수 있다. 보통 운영체제가 부팅 시 처음으로 설정한다고 한다.

프로그램이 쓰는 일반적인 메모리 영역은 당연히 캐시 가능할 것이다. 그래서 멀티 코어 환경에서도 CPU가 잘 알아서 캐시 코히런스를 맞춰주기 때문에 프로그램은 큰 걱정하지 않고 데이터를 읽어도 그 값의 정확함을 기대할 수 있다. (물론 여기에도 또 예외가 있다. 메모리 컨시스턴시, consistency 문제를 고려 하지 않으면 부정확한 값을 읽을 수 있다. 이 이야기는 복잡함으로 생략.)

그런데 이 책에서는 LED를 깜빡이게 하는 하드웨어를 제어하는 C코드를 예로 들면서 volatile을 설명하고 있다. 보통 이런 하드웨어에 접근할 때는 memory mapped I/O을 이용한다. 그냥 메모리에 값을 쓰는 것으로 바로 하드웨어에 접근한다. 이런 하드웨어에 매핑된 주소는 보통 캐시 되지 않도록 한다. 따라서 volatile로 선언된 주소가 캐시 불가능한 메모리 영역이라면 바로 주 메모리 혹은 해당 하드웨어 장치로 왔다 갔다 한다. 그렇다면 이 책의 설명은 어느 정도 옳다. 그러나 이런 내용이 나와있지 않아 초보자에게 혼동을 심어줄 수 있다.

실제 이 책에서는, 맨 위의 코드처럼, 하드웨어 주소를 가리키는 변수 하나와 단순히 시간 지연을 위한 for 루프의 변수 j, 이 두 개에 volatile을 붙인 뒤 설명하고 있다. 전자는 volatile로 바로 메모리에서 읽는 것이 말이 되지만 j의 경우에는 volatile이 있더라도 (일반적으로) CPU 캐시를 바로 지나치게 할 수는 없다.



요약하면:

C/C++ volatile 키워드는 컴파일러 최적화를 막아 레지스터에 그 값이 캐시되지 않도록 하여 바로 메모리의 값을 읽도록 하는데, 일반적인 경우, 여전히 CPU 내의 캐시는 최대한 활용된다.
volatile 키워드는 컴파일러, 프로그래밍 언어마다 그 뜻이 다르므로 잘 알아보고 쓰자. 특히 멀티스레디드 환경에서 함부로 쓰는 것은 주의해야 한다.
혹시 제가 잘못 알고 있다면 꼭 좀 알려주세요.

CPU는 x86 같은 범용 프로세서도 있지만 임베디드 환경에 쓰이는 특수한 녀석도 많다. 그래서 volatile 키워드 하나를 설명하는데도 많은 경우의 수를 고려해야 한다. 또, CPU도 시간이 지남에 따라 여러 기능이 추가 되기 때문에 단정적으로 말하기가 매우 힘들다. 그래서 “volatile이 있더라도 (일반적으로) CPU 캐시를..” 라는 문장처럼 “(일반적으로)”라는 작은 구멍을 만들었다. 나도 언제든지 틀릴 수 있기 때문이다.




1) x86에서 메모리(다시 한번, 여기서 말하는 메모리는 L1/L2/L3 및 주 메모리를 통칭하는 메모리 계층을 뜻) 읽기(load)와 쓰기(store) 명령은 CPU가 알아서 처리하므로 캐시를 지나치게 할 수는 없다. 그러나 SSE2 확장부터는 쓰기(store)에 대해서 캐시 오염(cache pollution)을 최소화 하는 명령을 지원한다. 그러니까 데이터를 쓸 때 캐시를 건들이지 않고 바로 메모리에 쓰는 것이다. 이런 메모리 명령을 non-temporal이라 부른다. Non-temporal 쓰기에는 MOVNTI, MOVNTDQ, MOVNTPD가 있다. 이게 왜 멀티미디어 확장 같은 SSE 명령에 있냐면, 이런 non-temporal 쓰기는 그래픽 비디오 메모리에 효과적으로 대역폭을 높일 수 있다.

반면, non-temporal 읽기는 SSE4.1에 와서 하나 추가 되었다. 바로 streaming read를 목적으로 하는 MOVNTDQA라는 명령어다. 이 명령은 캐시 가능하지 않은 메모리 영역에 대해 (또 weakly ordering을 지원하는 영역, 이 부분은 설명하고 싶지만 너무 글이 길어져 생략) 높은 대역폭으로, 캐시를 건들이지 않고, 데이터를 바로 레지스터로 가져오게 한다. 차차세대 인텔 CPU에는 이런 non-temporal 읽기가 더욱 강화된다고 한다.