C++ 키워드 중에서 다소 이해하기 어려운 것 중의 하나가 바로 "volatile"이 아닐까 싶은데요. 사실 잘 쓰지도 않는 키워드라서 별로 주의깊게 파고들지도 않기 때문에 더더욱 낯설게만 느껴지기도 합니다.
그래도 가끔은 결정적인 곳에서 곤란을 겪는 문제이기 때문에 혹시나 모르시는 분들은, 기왕에 이 토픽을 읽는 김에 확실히 알아두는 것도 좋겠습니다. 마침 저도, 최근에 읽었던 어느 블로그에서 이 문제를 곤란을 겪고 있는 분을 보고 답변을 한 김에 이렇게 작성하게 됩니다.
그 분의 문제는 다음과 같은 코드에서 발생했습니다.
class TestClass
{
public:
TestClass() : m_resultState(false), m_terminate(false) {}
bool result() { return m_resultState; }
void start()
{
DWORD threadID;
::CreateThread(NULL,0, _ThreadProc, this, 0, &threadID);
}
void endThread()
{
m_terminate = true;
while ( true) {
if ( true == result() ) {
break;
}
}
}
static DWORD WINAPI _ThreadProc(LPVOID lpParameter)
{
TestClass *pClass = (TestClass *)lpParameter;
int k = 0;
while ( pClass->m_terminate == false )
{
printf( "%d\n", k ++ );
Sleep(1000);
}
pClass->m_resultState = true;
return 0;
}
bool m_resultState;
bool m_terminate;
};
void _tmain(int argc, _TCHAR* argv[])
{
TestClass testClass;
testClass.start();
Sleep(2000);
testClass.endThread();
}
플래그를 이용해서 사용 중인 스레드를 종료시키는 것인데, 충분히 있을 법한 상황의 코드입니다.
문제는 위의 프로젝트를 Debug 모드로 컴파일하면 의도하던 대로 2초 후에 스레드 종료와 함께 콘솔 응용 프로그램이 정상적으로 종료하지만, Release 모드로 컴파일하게 되면 endThread 함수의 while 문이 무한 루프를 돌게 되는 현상이 발생합니다.
원인은 바로, "최적화"에 있습니다.
이 문제를 풀기 위해서는 우선 C++ 코드에 대한 어셈블리 코드를 보는 것이 가장 좋은데요. 다음과 같은 프로젝트 설정을 통해서 직접 어셈블리 파일을 생성해 줄 수도 있고,
또는 그냥 "F5" 키로 디버깅을 시작한 후, BP(Break Point)에서 멈추게 한 다음, 오른쪽 메뉴를 통해서 "Go To Disassembly" 메뉴를 선택하는 것도 좋은 방법입니다.
개인적으로 ^^ 간단한 것을 좋아하기 때문에 그냥 "Go To Disassembly"를 통한 어셈블리 코드 확인 창으로 확인해 보겠습니다.
위의 그림에서 보시는 것처럼, testClass.endThread 함수 호출 부분이 단순히 다음과 같은 어셈블리로 되어 있는 것을 볼 수 있는데요.
00401070 mov al, byte ptr [esp] // [esp] == 0
00401073 cmp al,1
00401075 jne wmain+33h (401073h)
최적화 결과로 인해 endThread가 함수로 되지 않고 그냥 inline 코드로 되어버렸고, al 레지스터의 값과 1을 비교하기 때문에 같을 때까지 jump 루프를 벗어나지 못하고 계속 위의 라인을 실행하게 되는 것입니다.
컴파일러 최적화 방법에 있어 "스레드 함수"는 전혀 예측할 수 없는 요소입니다. 따라서 모든 함수들이 순차적으로 단일한 스레드에 의해서 실행된다고 가정하기 때문에, 적어도 _tmain 함수를 실행하는 스레드에 의해서 실행되는 함수 중에는 m_resultState 변수 값을 바꾸는 코드가 없기 때문에 컴파일러는 그 값을 아예 0 값으로 미리 계산해 버리고 모든 코드를 최적화시켜 버리는 것입니다.
바로 이런 경우에, m_resultState 변수에 대해서 다른 스레드에 의해 "변경될 수 있다는(volatile)" 명시를 프로그래머가 직접 해주게 되면 컴파일러는 최적화를 하지 않게 되어 정상적으로 동작할 수 있게 됩니다. 위의 경우에는 m_resultState, m_terminate 변수를 다음과 같이 선언해 주어야 합니다.
volatile bool m_resultState;
volatile bool m_terminate;
이렇게 해주면 debug / release 모드에 상관없이 프로그램은 의도하던 대로 정상적으로 종료가 되어집니다.
하지만, 모든 경우에 이렇게 스레드와 관련되어 최적화가 빗나가는 것은 아닙니다. 다음과 같은 코드를 한번 보면,
class TestClass
{
public:
TestClass() : m_resultState(false) {}
bool result() { return m_resultState; }
void infiniteLoop()
{
while ( true)
{
if ( true == m_resultState )
{
break;
}
}
}
bool m_resultState;
};
void _tmain(int argc, _TCHAR* argv[])
{
TestClass testClass;
testClass.infiniteLoop();
printf( "%d\r\n", testClass.m_resultState);
}
이번엔 스레드와는 아무 상관없이 단지 infiniteLoop 함수만을 불러주고 있습니다. 이 경우, Debug 모드에서는 정상적으로(!) 무한 루프로 실행되지만, release 모드로 하면 그냥 종료되게 됩니다. 역시 이런 경우에도 release 모드에서 무한 루프로 실행되도록 하기 위해서는 m_resultState 선언에 volatile을 추가해 줘야 합니다.
가끔, 저는 정말 상식적으로 이해가 안 되는 버그를 만나곤 합니다. 그럴 때 기본적으로 먼저 의심하는 것이 (COM 을 많이 다루다 보니) vtable에 대한 구성에 문제가 없는지를 살펴보고, 이후에 최적화 문제를 살펴 보게 됩니다.
첨부한 파일은 위의 2가지 경우에 대한 테스트를 간단히 해보실 수 있도록 문제 재현을 할 수 있는 최소한의 소스 코드를 담은 프로젝트입니다.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]