멀티미디어 지식공작소 | [펌] 다중 쓰레드와 C++ [2]
멀티미디어 지식공작소 위치로그  |  태그  |  미디어로그  |  방명록
icon [펌] 다중 쓰레드와 C++ [2]
프로그램 기술/C/C++/MFC | 2008. 2. 3. 18:21
출처 블로그 > dividebyzero님의 블로그
원본 http://blog.naver.com/dividebyzero/100019831257

쓰레드 핸들의 경우에는 초기의 레퍼런스 카운트가 2가 되는 특징을 가지고 있다. 하나는 CreateThread를 호출한 클라이언트에게 반환되는 핸들을 위한 레퍼런스이고, 다른 하나는 쓰레드 스스로를 위한 레퍼런스이다. 후자의 레퍼런스는 쓰레드가 종료한 경우에 감소한다. 이러한 사실을 통해 다음과 같은 점을 생각해 볼 수 있다.

쓰레드 핸들의 특징
쓰레드를 생성하자마자 CloseHandle()을 호출하는 것이 쓰레드를 종료하게 만들지는 못한다. 단순히 클라이언트에 주어진 레퍼런스만 하나 감소하고 쓰레드는 여전히 동작하게 된다. 나중에라도 이 클라이언트가 쓰레드의 상태를 검사할 일이 없다면, 굳이 HANDLE을 보관할 필요가 없기 때문에 오히려 쓰레드를 생성하자마자 CloseHandle()을 호출하는 것이 바람직할 수도 있다.

마찬가지로 쓰레드가 종료된 이후에도 클라이언트가 아직 쓰레드 핸들을 닫지 않았다면 핸들의 레퍼런스 카운트는 1이 되어 아직 살아있게 된다. 이 경우에 쓰레드는 종료되었지만 쓰레드 핸들을 가지고 작업을 하는 것은 가능하다. 예를 들어 GetExitCodeThread()를 사용해 쓰레드의 반환 값을 확인할 수 있다. 물론 쓰레드 핸들을 닫은 후에는 이러한 작업이 불가능하다.

HANDLE로 다뤄지는 커널 객체들의 또 한 가지 공통점은 신호를 받은 상태 혹은 신호를 받지 않은 상태를 가지고 있다는 점이다. 예를 들어 이벤트의 경우에는 SetEvent()를 했을 때 신호를 받은 상태가 되고 ResetEvent()를 했을 때 신호를 받지 않은 상태가 된다. 프로세스나 쓰레드 핸들의 경우에는 처음 생성시에는 신호를 받지 않은 상태이고 종료된 경우에 신호를 받은 상태가 된다. 이러한 상태를 활용하는 대표적인 API가 바로 WaitForSingleObject(), WaitForMultipleObjects(), MsgWaitForMultipleObjects()이다.

이러한 API는 HANDLE을 입력 인자로 가지고 있는데, 입력된 핸들이 신호를 받을 때까지 기다리는 기능을 수행한다. 예를 들어 이벤트 핸들의 경우에는 이벤트가 셋(SET)될 때까지 기다렸다가 번환하며, 프로세스나 쓰레드의 경우에는 종료할 때까지 기다렸다가 반환한다. <리스트 1>처럼 main() 함수의 끝부분에 WorkerThread가 종료할 때까지 기다리는 코드를 볼 수 있을 것이다.

CRT를 올바르게 사용하자
CRT(C Run-Time Library)는 우리가 처음 C++ 언어를 배울 때부터 사용하던 많은 함수와 매크로가 포함되어 있다. 대표적인 printf() 함수부터 시작해서 메모리를 할당/해제 함수, 전역 변수의 생성자를 호출해 주는 기능까지 모두가 CRT의 기능이다.


<화면 1> CRT의 종류를 보여주는 등록정보 창


이 CRT는 lib나 dll의 형태로 프로그램에 링크되는데, 성능상의 이유로 인해 다중 쓰레드 버전과 단일 쓰레드 버전으로 나눠져 있다. 다중 쓰레드 버전에서는 단일 쓰레드 버전과는 달리 동기화 코드가 추가되어 있는데, 프로그램이 단일 쓰레드만 가지고 있다면 굳이 이런 동기화 코드로 인한 부담을 껴안을 필요는 없다. 반면에 다중 쓰레드를 사용하는 경우에는 이런 동기화 코드가 반드시 필요하다. 즉, 자신의 쓰레드 사용 여부에 맞는 버전의 CRT를 링크할 필요가 있다는 것이다. <화면 1>과 <화면 2>는 비주얼 스튜디오 닷넷에서 CRT의 종류를 고를 수 있는 등록정보 창과 CRT의 종류를 보여주고 있다.
<리스트 2>는 CRT를 올바르게 선택하는 것이 중요하다는 사실을 보여주기 위해 준비한 예제다. GetLastError() API와 비슷하게 CRT에도 현재 쓰레드의 최근 에러 값을 보관하고 있는 errno 변수가 존재한다. <리스트 2>를 단일 쓰레드 버전의 CRT와 링크한 경우에는 작업 쓰레드의 최근 에러 값이 엉뚱하게 나오는 것을 확인할 수 있다.

   <리스트 2> CRT의 사용 예

#include
#include
#include
using namespace std

DWORD WINAPI WorkThread(LPVOID);

void main()
{
      // Result too large(34) 에러를 발생시킨다.
      pow( INT_MAX, INT_MAX);

      // 메인 쓰레드의 최근 에러 번호 출력
      cout << "Main : " << errno << endl

      // 작업 쓰레드 시작
      DWORD dwID
      HANDLE h = CreateThread(NULL, 0, WorkThread, NULL, 0, &dwID);

      // 종료 처리
      WaitForSingleObject(h, INFINITE);
      CloseHandle(h);
}

DWORD WINAPI WorkThread(LPVOID)
{
      // 작업 쓰레드의 최근 에러 번호 출력
      cout << "WorkThread : " << errno << endl
      return 0
}

// 결과 1 : 다중 쓰레드 버전의 CRT와 링크한 경우
Main : 34
WorkThread : 0

// 결과 2 : 단일 쓰레드 버전의 CRT와 링크한 경우
Main : 34
WorkThread : 34


마이크로소프트에서 제공하는 CRT에는 _beginthread와 _beginthreadex 두 가지의 쓰레드 생성 함수가 있다. 이 함수들이 성공적으로 호출되면 정수 값을 반환하는데, 타입은 다르지만 쓰레드의 핸들이다. _beginthread를 사용한 경우에 생성된 쓰레드에서는 _endthread를 호출해 자기 자신을 종료시킬 수 있는데 이때는 자동으로 CloseHandle()을 호출해 쓰레드 핸들을 닫아준다. 반면에 _beginthreadex와 _endthreadex를 사용한 경우에는 직접 CloseHandle()을 호출해 줄 필요가 있다. 물론 MSDN에 잘 설명되어 있지만 모르고 지나치기 쉬운 부분이니 주의해서 사용하길 바란다.

쓰레드 간의 데이터 전송
이번에는 쓰레드 간에 데이터를 전송하는 시나리오를 상상해 보자. 우리 주변에서 찾아 볼 수 있는 아주 흔한 예로는 동영상 파일을 읽어서 화상을 출력하는 것이 있다. 첫 번째 쓰레드(A)는 동영상 파일에서 특정 단위만큼씩 읽어서 다음 쓰레드(B)로 보내는 일만 열심히 한다. 다음 쓰레드(B)는 받은 데이터를 디코딩해 그 다음 쓰레드(C)로 보내는 일만 열심히 한다. 마지막 쓰레드(C)는 받은 데이터를 화면에 출력하는 일만 열심히 한다. 일반적으로 파이프라인이라고 부르는 작업 방식과 동일한 것이다.

다만 하드웨어 상에서의 파이프라인은 실제로 동시에 실행될 수 있어서 확실한 성능 향상을 가지고 오지만, 쓰레드를 사용한 파이프라인은 결국 한 CPU가 컨텍스트 스위칭을 해가면서 구현하는 것이기 때문에 I/O 연산이 연관된 경우에만 성능 향상을 기대할 수 있다. 파일에서 데이터를 읽는 것이나 화면에 이미지를 출력하는 것 모두 I/O 연산이기 때문에 동영상 파일을 읽어서 화상을 출력하는 경우는 다중 쓰레드를 적용하기에 아주 좋은 후보라고 볼 수 있다. 다이렉트X SDK에는 멀티미디어 데이터와 관련된 다이렉트쇼 SDK를 포함하고 있으며 실제로 다이렉트쇼는 이와 같은 방식으로 동작하고 있다.
이 시나리오에서 관심을 가지고 생각해 볼 부분은 데이터를 전송하는 방법이다. 쓰레드 간에는 함수 호출과 같은 방식으로 데이터를 넘겨주는 것이 불가능하다. 함수 호출을 해보았자 결국은 자신의 쓰레드이기 때문이다. 별도의 버퍼를 두어서 그것을 공유하는 방법이 일반적이다. 앞서 예를 든 쓰레드 A가 동영상 파일의 일부를 버퍼에 복사해 두면 쓰레드 B가 그 버퍼에서 읽어서 작업하는 방식이다(<그림 3-a>).

그러나 쉽게 예상할 수 있듯이 쓰레드 B가 버퍼에서 데이터를 읽는 도중에 쓰레드 A가 버퍼에 데이터를 쓰게 되면 쓰레드 B는 망가진 데이터를 읽게 된다. 그렇기 때문에 이 버퍼는 CriticalSection이나 Mutex와 같은 동기화 객체를 사용해 보호될 필요가 있다(CriticalSection이 더 적은 오버헤드를 갖기 때문에 프로세스간의 동기화가 아니라면 CriticalSection을 쓰는 것이 일반적이다).

이렇게 동기화를 추가한 후에는 한 쓰레드가 버퍼에 작업 중인 동안에 다른 쓰레드가 작업할 수 없는 문제가 생긴다. 다른 쓰레드의 작업을 기다리는 만큼의 시간을 손해보는 것이다. 이런 문제를 해결하기 위해서는 버퍼를 두 개로 늘리는 방법을 사용하면 된다(보통 이중 버퍼링이라고 불린다)(<그림 3-b>). 버퍼가 두 개로 늘어나면 한 쓰레드가 한 쪽 버퍼에 작업하는 동안에도 다른 쓰레드가 다른 쪽 버퍼에 작업할 수 있기 때문에 기다리는 시간을 줄일 수 있다. 물론 이런 경우에도 문제는 남아 있다. 두 쓰레드가 언제나 맞아 떨어지게 작업하는 것은 아니기 때문이다. 예를 들어 순간적으로 쓰레드 B의 작업이 지체되면 두 개의 버퍼가 다 차버리고, 쓰레드 A는 다음 번 데이터를 버퍼에 쓰기 위해 쓰레드 B가 버퍼의 내용을 읽어가기를 기다려야 하기 때문이다.

이중 버퍼링의 장단점
이러한 문제점을 해결하기 위한 방법으로 다수 개의 버퍼를 사용하는 방법을 생각할 수 있다. 익히 알고 있는 큐(Queue)가 바로 그것이다. 그런데 큐를 사용한다고 하더라도 크게 두 가지의 정책을 세울 수가 있다. 하나는 최대 버퍼의 수를 제한하는 방식이고 다른 하나는 무한으로 버퍼의 수를 증가시키는 방식이다. 두 가지 방식은 각각 장단점을 가지고 있다. 우선 최대 버퍼의 수를 제한하는 방식의 장점은 무한으로 메모리를 요구하는 것을 막을 수 있다는 점이다.

또한 버퍼의 수가 한계에 도달해 쓰레드 A가 중단된 상태로 기다리는 동안 CPU에 그만큼의 여유가 생겨서 쓰레드 B가 훨씬 많은 CPU 자원을 사용할 수 있게 된다. 그렇게 되면 자동으로 쓰레드 B가 큐에 쌓인 데이터를 읽어서 처리하는 속도가 빨라지고 프로그램의 전체적인 부하가 해소된다. 무한으로 버퍼를 제공하는 경우에는 쓰레드 B가 소화하지 못할 만큼의 데이터가 계속해서 큐에 쌓이므로 프로그램이 원활하게 동작하지도 않을 뿐더러 결국에는 메모리가 부족해 작업을 계속 할 수 없게 될 수도 있다. 물론 쓰레드 B가 I/O 요청을 기다린다거나 특정 조건을 기다리는 등의 이유로 작업이 정체되는 경우라면 쓰레드 A가 중단되는 것이 도움이 되지는 않을 것이다.

최대 버퍼의 수를 제한하는 경우에도 버퍼의 수가 한계에 도달했을 때의 처리 방식에 따라 크게 두 가지 정책을 세울 수가 있다. 하나는 여유분의 버퍼가 생길 때까지 쓰레드 A가 중단되어 기다리는 방식이며, 또 다른 하나는 버퍼 중에 하나를 강제로 비워버리는 방식이다. 선택의 기준은 달성하고자 하는 목적과 관계가 있다. 예를 들어 지금 사용하고 있는 예제인 동영상의 경우에, 그 중에서도 화상인 경우에는 버퍼 중에 하나를 버리는 방식을 사용하기에 적당하다.

화상의 경우에는 중간에 몇 프레임이 없어져도 사용자에게 크게 불편함을 주지 않기 때문이다. 또한 화상의 디코딩은 CPU를 많이 소모하는 작업이기 때문에 프로그램의 부하를 낮추는데도 많은 도움을 준다. 반면에 음성인 경우에는 버퍼 중에 하나를 버리는 방식을 사용하기에 적절하지 않다. 음성 데이터 한 프레임이 버려진다는 것은 영화의 배경음악이 끊긴다거나 주인공의 말소리가 잘리는 결과를 가져오기 때문에 화상에 비해 크게 거슬리게 된다. 물론 이러한 것들은 필자가 주로 하던 작업과 관련된 아주 단편적인 예이며 여러분의 환경에 맞는 적당한 정책을 수립할 필요가 있을 것이다.
이렇게 큐를 사용해 쓰레드간의 데이터 전송을 구현할 때 데이터를 매번 큐 내부의 버퍼에 복사하고, 복사해 오는 작업은 많은 부하를 발생시킨다. 그래서 큐에는 단순히 포인터만 유지하는 것이 일반적이다. 버퍼를 매번 생성하고 소멸시키는 것도 시간을 소모하는 작업이므로 미리 버퍼를 만들어 두어서 버퍼 풀(buffer pool)에 넣어두고 꺼내 쓰는 방법도 일반적이다. <그림 4>를 보면서 살펴보자. 쓰레드 A는 버퍼 풀에서 버퍼를 하나 얻어서 동영상의 일부를 읽는다. 그리고는 해당 버퍼의 포인터를 큐에 넣는다. 쓰레드 B는 큐에서 버퍼의 포인터를 얻어서 디코딩 작업을 한다. 사용이 끝난 버퍼는 다시 버퍼 풀로 반환해서 재사용할 수 있도록 한다.


<그림 4> 버퍼 풀의 사용


UpdateWindow() API
이번 기사의 마무리를 장식할 주제는 UpdateWindow()라는 API이다. 이 API는 윈도우 프로그래밍을 처음 시작할 때부터 등장한다. 기본적인 WinMain() 함수의 구현에서 CreateWindow()와 메시지 루프 사이에 위치한다. 처음 공부할 때 윈도우가 바로 화면에 그려지게 하는 역할을 한다고 배웠지만 UpdateWindow() 를 호출하지 않더라도 윈도우는 잘 그려졌기 때문에 의아해 하면서 넘어갔던 기억이 난다. 하지만 올해 초에 GUI 환경에서 단일 쓰레드를 사용하는 경우에 UpdateWindow()를 매우 유용하게 사용할 수 있음을 알게 되었다. 우선 <화면 3>을 살펴보자.

‘Test’ 버튼을 누르면 텍스트 박스에 1부터 100까지의 정수를 차례로 넣는 예제이다. 이 때 UpdateWindow()를 사용할 것인지 결정할 수 있는 옵션을 가지고 있는데, 그에 따라 서로 다른 결과를 보여준다. 옵션을 체크한 경우에는 예상대로 1부터 100이 차례로 보여지지만 체크하지 않은 경우에는 한참 후에 100만 보여진다.

코드를 보면 알 수 있지만 UpdateWindow()가 에디트 컨트롤이 바로 바로 자신을 다시 그리게 해주기 때문이다(이 예제는 MFC 프로젝트이다). SetWindowText()는 에디트 컨트롤의 내용을 바꾸고 WM_PAINT를 발생시키는 역할을 하지만 그 메시지는 바로 처리될 수 없다. OnBnClickedBtnTest() 함수는 메인 쓰레드에서 실행되기 때문에 이 함수가 완료될 때까지 메시지 루프가 실행될 수 없고, 그에 따라 WM_PAINT가 윈도우 프로시저에 전달될 수 없기 때문이다. 그러나 UpdateWindow()를 호출해 주면 WM_PAINT 메시지를 바로 윈도우 프로시저에 전달해 주기 때문에 에디트 컨트롤에 바로 그려질 수 있다.


void CUpdateWindowDlg::OnBnClickedBtnTest()
{
      TCHAR temp[16];
      CWaitCursor wait

      UpdateData(TRUE);

      // 천천히 숫자를 증가시킨다.
      for (int i = 0 i <= 100 ++i)
      {
            m_edit.SetWindowText( _itot( i, temp, 10) );

            // 옵션에 따라 UpdateWindow() 호출
            if (m_bUseUpdateWindow)
               m_edit.UpdateWindow();

            // 테스트 용도
            Sleep(20);
      }
}


필자가 UpdateWindow()를 사용하기 전에는 컨트롤이 바로 바로 갱신될 수 있도록 하기 위해 별도의 작업 쓰레드를 생성해 사용했다. 그러나 앞서 설명한 반응성이 중요하지 않다면 단일 쓰레드를 사용할 것을 권장하고 싶다. 이 기사를 제대로 읽은 독자라면 그 이유를 알 수 있을 것이라 생각한다. 쓰레드를 즐겨 사용하던 필자는 UpdateWindow()를 사용해 같은 문제를 해결할 수 있다는 점을 알았을 때 많은 교훈을 얻을 수 있었다. 그것이 어떤 종류의 교훈이었을지는 여러분의 상상에 맡기도록 하겠다.

소스 코드를 통해 배워라
필자는 다른 사람의 소스 코드를 분석하는 것을 좋아하지 않는다. MSDN 라이브러리나 잡지, 책을 읽는 것이 더 쉽고, 더 많은 지식을 준다고 생각하기 때문이다. 처음에도 말했듯이 필자는 이번 학기에 오픈소스 프로젝트 하나를 분석하고 있는데, 이 과정에서 얻은 교훈이 한 가지 있다. 나쁜 책을 통해 배울 수 있는 것보다는 나쁜 소스 코드를 통해 배울 수 있는 것이 더 많다는 점이다. 자신의 결점보다는 다른 사람의 결점이 더 잘 보이는 것이 사람이기 때문인 것 같다. 이 기사에서 부족한 점을 많이 느꼈다면 다음 번에 여러분이 기사를 쓸 때 좋은 거름이 될 거라는 생각으로 이해를 구한다.

@박은정 기자 (마이크로소프트웨어)


arrow 트랙백 | 댓글



관리자  |   글쓰기
BLOG main image
- 블로그를 처음 만들면서
분류 전체보기 (142)
기술동향 뉴스 (51)
신조어 사전 (1)
기술용어집 (5)
영상처리 기술 (29)
IT 사용정보 (7)
프로그램 기술 (23)
학술정보 (1)
생활정보 (9)
낙서장 (13)
나의 이야기 (0)
About Me (0)
Total :
Today :
Yesterday :
rss
위치로그 : 태그 : 방명록 : 관리자
multimedia's Blog is powered by Daum / Designed by plyfly.net