프로젝트에 다중 쓰레드를 도입하면 동기화나 종료 처리 등의 문제로 고려해야 할 사항들이 곱절 이상이나 늘어나게 된다. 그럼에도 불구하고 다중 쓰레드를 사용하는 이유는 프로그램의 성능을 향상시켜 주기 때문이다. 여기서 성능을 향상시켜 준다는 말이 무엇을 의미하는지는 좀더 생각해 볼 필요가 있다. 또한 어떻게 해야 성능이 향상되는지도 알아 볼 필요가 있다.

다중 쓰레드에 대해 공부해 본 적이 있다면 많은 책과 기사에서 다중 쓰레드의 사용을 될 수 있으면 자제하라고 권장한다는 사실을 알고 있을 것이다. 일단 프로젝트에 다중 쓰레드를 도입하면 동기화나 종료 처리 등의 문제로 고려해야 할 사항들이 곱절 이상이나 늘어나게 된다.

상식적으로 생각해도 알 수 있듯이 코드 한 줄을 고치는 데도 많은 고민을 해야 하며, 문제 상황이 항상 재현되는 것이 아니기 때문에 디버깅 시에도 많은 고생을 하게 된다. 그럼에도 불구하고 다중 쓰레드를 사용하는 이유는 프로그램의 성능을 향상시켜 주기 때문이다. 그런데 여기서 성능을 향상시켜 준다는 말이 무엇을 의미하는지는 좀더 생각해 볼 필요가 있다.

또한 어떻게 해야 성능이 향상되는지도 알아 볼 필요가 있다. 실제로 다중 쓰레드를 사용한 프로젝트 중에는 성능 향상은 별로 보이지 않고, 다중 쓰레드 도입으로 인한 문제점만 고스란히 떠안고 있는 경우가 많기 때문이다.

다중 쓰레드의 도입 시기
컴퓨터에 설치된 MSDN이나 웹에서 ‘Win32 Multithreading Performance’라는 제목의 기사를 찾아보자. 이 기사는 1996년도 1월에 작성된 기사이지만 언제 다중 쓰레드를 적용하는 것이 좋은지 아주 훌륭하게 설명하고 있다. 그렇기 때문에 필자는 새로운 설명 방식과 예제를 구상하는 시간에 차라리 이 기사의 주요 내용에 자세한 설명과 그림을 추가해 여러분의 이해를 돕는 것이 더 효율적일 것이라는 결정을 내렸다. 이 단락을 읽고 나면 여러분은 어떤 상황에서 다중 쓰레드를 사용해야 하는지 판단할 수 있는 능력을 지니게 될 것이다. 크게 세 가지의 주요 관점을 기준으로 설명을 하려고 한다.

전체 작업의 완료 시간
CPU가 하나만 존재하는 시스템에서 실제로 두 작업이 동시에 실행되는 것은 불가능하다. CPU가 아주 짧은 시간 간격으로 두 작업을 번갈아가며 실행시키기 때문에 우리에게 마치 동시에 실행되는 것처럼 느껴지는 것뿐이다. 이 때 우리가 간과해서는 안될 사실은 두 작업 사이를 오가는 과정(context switching)에서 오버헤드가 발생한다는 점과 쓰레드를 생성하는 일 역시 시간을 소모하는 작업이라는 점이다. 예를 들어 두 개의 작업 A, B가 있다고 하자. 이 경우 다중 쓰레드를 사용한 경우와 그렇지 않은 경우의 전체 작업의 완료시간은 다음과 같다. 다중 쓰레드를 사용한 경우가 보다 비효율적이라는 것을 알 수 있다

하지만 이는 A, B가 작업 시간 내내 순수하게 CPU만 사용한다는 가정에서만 성립된다. A, B의 작업 시간 중에 I/O 요청을 기다리는 시간이 포함된다면 문제가 달라진다. 예들 들어 A의 주요 작업 내용이 메모리의 데이터를 특정 파일에 기록하는 것이라고 가정하자. 파일에 기록하는 작업은 하드디스크와 같은 하드웨어에 기록을 요청한 후에 하드웨어에서 완료 응답이 도착할 때까지 기다리는 방식으로 진행된다. 그런데 이렇게 하드웨어의 응답을 기다리는 동안에는 CPU를 사용하지 않기 때문에 다른 작업이 CPU를 사용할 수 있다. 다시 말해 A가 I/O 요청을 기다리는 동안에는 B가 자신의 작업을 수행할 수 있다는 말이다. 그래서 다중 쓰레드를 사용한 경우 전체 작업의 완료 시간은 다음과 같이 다시 계산될 수 있다.

결론적으로 I/O 작업은 다중 쓰레드의 좋은 대상이 된다고 할 수 있다. 운영체제의 발전 역사를 보더라도 하나의 시스템에 여러 사용자 프로그램을 동시에 적재해 실행하기 시작한 계기도 한 프로세스가 I/O 요청을 기다리는 동안에 다른 프로세스가 CPU를 사용할 수 있다는 사실을 운영체제 설계자들이 깨달았기 때문이다.

평균 처리 시간
앞서 CPU 연산의 경우 다중 쓰레드는 전체 작업 완료 시간을 단축하는 데 도움이 되지 않는다는 점을 확인했다. 그러나 우리의 관심사를 평균 처리 시간으로 옮기게 되면 CPU 연산의 경우에도 다중 쓰레드를 사용해 성능을 향상시킬 수 있다는 점을 확인할 수 있다. <그림 1>을 보면서 설명하도록 하겠다.

작업 A, B, C는 각각 1, 4, 3의 작업 시간을 갖으며 CPU 연산이다. 이 때 A, B, C의 순서대로 작업을 실행시킨다고 해보자. 그러면 작업 A는 바로 시작해서 작업 시간인 1만큼의 시간이 경과한 후에 완료될 것이다. 작업 B의 경우는 A가 끝나는 시간인 1만큼 기다렸다가 작업 시간인 4만큼의 시간이 경과한 후에 완료될 것이다. 전체적으로 볼 때 작업 B는 5만큼의 시간이 지난 후에 완료되는데 이 시간을 처리 시간(Turnaround Time)이라고 부르도록 하자.

같은 식으로 C의 처리 시간은 8이 된다. 이 글에서는 이러한 처리 시간의 평균을 ‘평균 처리 시간’이라고 부르도록 하겠다. 이제부터 우리는 다중 쓰레드를 사용하는 것이 어떻게 평균 처리 시간을 줄일 수 있는지 확인시켜 줄 예제 하나를 보게 될 것이다.

<그림 2> 평균 처리 시간의 감소 예

이런 종류의 문헌에서 자주 등장하는 슈퍼마켓에서의 계산 예를 들어보자. 슈퍼마켓에서 여러 손님들이 자신이 필요한 물건을 고른 후에 계산을 하려고 한다. 그리고 점원은 딱 한 명밖에 없다. 한 명의 점원이 여러 손님의 물품을 계산하는 방법으로 크게 두 가지를 생각해 볼 수 있다. 하나는 사람들을 한 줄로 세우고 차례로 계산을 해주고, 다른 하나는 여러 개의 계산대에 사람들을 여러 줄로 세우고 한 번에 한 계산대씩 돌아가면서 차례로 계산을 해주는 방법이다. 그림을 좀더 설명하면 이렇다.

각 손님마다 계산해야 할 물품의 개수가 적혀져 있는데 점원은 한 번에 하나씩 물품 계산을 한다고 가정한다. 즉, 10개의 물품을 가진 손님은 5개의 물품을 가진 손님보다 계산 시간이 두 배가 길어지게 된다. 마찬가지로 두 번째 방법의 경우에도 점원이 한 번에 한 물품만 계산하게 된다. 즉, 손님이 가지고 온 물품 중에 하나만 계산하고 다른 계산대로 이동하는 방식이다. 두 방법은 각각 다중 쓰레드를 사용한 경우와 사용하지 않은 경우를 비유하기 위한 것이다. 각 손님은 작업에 해당하며, 손님이 가지고 있는 물품은 작업 시간에 해당한다. 계산대 혹은 손님들의 줄은 하나의 쓰레드에 해당하고, 점원은 CPU에 해당한다. 따라서 두 번째 방법은 다중 쓰레드를 비유하고 있다는 점을 쉽게 알 수 있을 것이다.

그림을 보면 물품을 한 개만 가지고 있는 손님이 보일 것이다. 여러분이 그 손님이라고 상상해 보자. 첫 번째 그림에서 계산을 끝내고 슈퍼마켓을 나오기 위해서는 10 + 5 + 2 + 8 + 1 = 26만큼의 시간이 걸릴 것이다. 반면에 두 번째 그림에서는 5만큼의 시간 후에 슈퍼마켓을 나올 수 있다. 즉, 전체 손님을 놓고 볼 때는 이득이 없지만 여러분 입장에서는 많은 시간을 벌 수 있는 것이다. 그러면 두 그림의 경우에서 평균 처리 시간은 어떻게 되는지 계산해 보자. 첫 번째 그림은 직관적이지만 두 번째 그림의 경우는 연습장에 그려가면서 계산해야 이해가 쉽다.

예상했던 것처럼 두 번째 그림의 경우에 평균 처리 시간이 적은 것을 볼 수 있다. 이제는 다중 쓰레드를 사용하는 것이 어떻게 평균 처리 시간을 줄일 수 있는지 이해할 수 있을 것이다.

그런데 앞의 예처럼 작업 시간을 미리 알 수 있는 경우라면 다중 쓰레드를 사용하지 않더라도 평균 처리 시간을 최소로 만들 수 있다. 작업 시간이 작은 작업을 먼저 수행하면 최소의 평균 처리 시간을 얻을 수 있는 것이다. 다시 말해 작업을 1, 2, 5, 8, 10의 순서로 진행하면 평균 처리 시간이 1 + (1+2) + (1+2+5) + (1+2+5+8) + (1+2+5+8+10) = 54/5로 가장 작은 값을 갖는다. 이런 방식으로 정렬하는 경우에 최소의 평균 처리 시간을 얻을 수 있다는 사실은 직관적으로도 알 수 있으며 쉽게 증명할 수 있다.

또 한 가지 간과하기 쉬운 사실이 있다. <그림 2>의 두 번째 그림에서 5명의 손님이 같은 셔틀 버스를 타고 집에 가야 하는 경우를 생각해 보자. 아무리 일찍 계산을 마치고 나왔다 하더라도 결국은 마지막 손님이 계산을 마치고 셔틀버스에 탈 때까지 기다려야 한다. 바꿔 말해 다중 쓰레드를 사용해 처리된 작업들의 결과가 결국은 한 데 모여야지만 된다면 평균 처리 시간을 줄이는 것은 아무런 의미가 없게 되는 것이다.

반응성
지금까지 살펴본 것 외에 다중 쓰레드를 적용해 달성할 수 있는 요소 중에 한 가지는 반응성이다. 이는 실제적인 예를 들어 설명하는 것이 더 이해하기 쉬울 것 같다. 압축 프로그램을 만든다고 생각해 보자. 만약에 다중 쓰레드를 적용하지 않고 압축 해제 루틴을 구현하게 된다면 사용자는 압축 해제가 끝날 때까지는 작업을 취소할 수 없을 것이다. 사용자가 예상 시간이 30분이나 되는 압축 파일을 풀다가 취소를 하려고 했다면 사용자는 프로그램을 강제로 종료시켜 버리고는 다시는 쓰지 않을 것이다. 반면에 별도의 쓰레드에서 압축 해제 작업을 하는 경우에는 사용자의 입력을 받을 수 있기 때문에 취소 기능을 구현하는 것이 가능하다. 즉, 사용자의 요청에 빠르게 반응하는 프로그램을 만들 수가 있다.

volatile 키워드의 사용
안타깝게도 C++를 사용해 쓰레드를 생성하고 제어하기 위한 코드는 플랫폼마다 다른 형식을 취하고 있다. 이는 쓰레드를 사용하는 프로젝트의 이식성을 떨어뜨리는 주요 원인 중 하나이다. 그러나 지난 번 기사에서 소개한 boost 라이브러리에는 플랫폼에 독립적인 쓰레드 클래스를 가지고 있으니 한번 확인해 보는 것도 좋을 것이다.
C++에는 volatile 키워드가 있는데, 사전 그대로 말하자면 ‘휘발성의’, ‘변덕이 심한’이라는 뜻이다. 이 키워드는 C++를 사용해 다중 쓰레드를 구현하는데 있어서 아주 중요한 역할을 한다. <리스트 1>은 하나의 작업 쓰레드를 가지고 있는 간단한 프로그램인데, 이를 릴리즈 버전으로 컴파일한 경우 올바르게 동작하지 않는다. 설명을 보기 전에 스스로 문제점을 찾아보도록 하자.

힌트는 디버그 버전에서는 문제없이 돌아가고 릴리즈 버전에서만 문제가 발생한다는 점이다. 릴리즈 버전에서는 기본적으로 최적화를 수행하게 된다. 안타깝게도 최적화를 수행하는 컴파일러는 우리의 의도를 완벽하게 이해할 수 없다. WorkerThread 함수 안에서 finish 변수의 값을 true로 설정하는 곳이 없기 때문에 while(finish)을 while(true)처럼 바꿔도 아무런 상관이 없을 것이라고 생각하는 것이다. 물론 매번 finish 변수에 접근하지 않아도 되기 때문에 속도 향상은 있겠지만 <리스트 1>의 경우엔 잘못된 판단이 아닐 수 없다.

결론적으로 main() 함수에서 finish 변수에 true 값을 넣어도 작업 쓰레드는 종료되지 않고 메인 쓰레드 역시 작업 쓰레드를 계속 기다리기 때문에 프로그램이 종료될 수 없다. 이 문제를 해결하는 방법은 매우 간단하다. volatile bool finish = false;과 같이 volatile 키워드를 넣어서 finish 변수를 선언하면 컴파일러는 함부로 finish 변수와 관련된 코드를 최적화하지 않는다.

HANDLE과 쓰레드 핸들
CreateThread() 함수가 성공적으로 호출되면 쓰레드의 핸들을 반환하게 된다. 아마도 여러분은 HANDLE 타입이 쓰레드 핸들을 담는 용도 외에 여러 곳에서 사용되는 것을 보았을 것이다. 파일 핸들이나 프로세스 핸들, 뮤텍스나 이벤트 같은 동기화 객체의 핸들 역시 HANDLE 타입으로 다뤄진다. 이렇게 HANDLE 타입으로 다뤄지는 객체들의 공통점은 커널 객체라는 점이다. 커널 객체라는 공통점을 가지고 있기 때문에 몇 가지 특징을 공유하고 있다.

기본적으로 이러한 핸들은 레퍼런스 카운팅 방식으로 동작한다. 이는 COM 객체가 레퍼런스 카운트를 유지하다가 마지막 클라이언트가 릴리즈했을 때 레퍼런스 카운트가 0이 되어 소멸되는 것과 같은 방식이다. 이벤트 객체를 처음 생성한 경우에는 레퍼런스 카운트가 1이 된다. 그리고 나서 CloseHandle()을 사용해 핸들을 닫아주면 레퍼런스 카운트가 하나 줄어 들어 0이 되고, 실제로 객체가 소멸된다. 커널 객체는 프로세스가 아닌 커널의 소유이다.

그렇기 때문에 커널 객체를 생성한 프로세스가 종료되더라도 다른 프로세스에서 해당 커널 객체를 사용중이라면 커널 객체는 살아있는 채로 유지된다. 한 가지 알아둘 점은 윈도우 98 계열의 운영체제에서는 이미 소멸된 커널 객체에 대해 CloseHandle()을 호출해도 아무런 반응이 없는 반면에 윈도우 NT 계열의 운영체제에서는 예외가 발생한다는 점이다. 만약에 다중 쓰레드를 사용하는 프로그램이 윈도우 98에서 잘 동작하다가 윈도우 2000에서 예외를 발생시킨다면 쓰레드의 종료 처리를 의심해 볼 필요가 있다. @박은정 기자 (마이크로소프트웨어)