Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>
Docbook 원문

Pthread(3) - 더 깊이

Pthread(3) - 더 깊이

윤 상배

dreamyun@yahoo.co.kr



1절. 소개

그동안 Pthread(1)Pthread(2) 를 통해서 pthread(:12) 에 대한 기본적인 개요와 사용방법을 알아 보았다. 이번문서는 pthread 에 대한 좀더 깊이있는 내용에 대해서 알아보도록 하겠다.

이 문서에서는 그동안의 Pthread 문서에서 다루지 못한 몇가지 이슈들과 다중 쓰레드 프로그래밍시 필요로하는 Condition:::variables(:12) 를 통한 좀더 정교한 쓰레드간 동기화 방법에 대해서 다루게 된다.


2절. 쓰레드 종류

2.1절. User Space 과 Kernel Space 쓰레드

Pthread 는 Posix:::Thread(:12) 로 Posix 에서 표준으로 규격화한 쓰레드 라이브러리(:12)이며, User:::Space(:12) 에서 작동하는 쓰레드 라이브러리이다. 즉 쓰레드 관리를 위해서 Kernel 이 관여를하지 않고 쓰레드 관련 라이브러리에서 대부분의 쓰레드 관리를 처리하게 된다. Kernel 이 직접 쓰레드를 관리하는 방식을 Kernel:::Space(:12) 쓰레드 라고 하는데, User Space 쓰레드 보다 비용이 좀더 많이 드는 관계로 최근에는 User Space 라이브러리를 좀더 선호하는 편이다.

Kernel Space 이 User Space 쓰레드 보다 비용이 더 많이 든다는데 의아해 할수도 있을것이다. 일반적으로 생각했을때 Kernel 은 좀더 시스템에 가까우므로 좀더 비용이 적고 빠를것 이라고 생각할수 있지만 실은 그렇지 않다. 보통 응용프로그램은 2가지 레벨에서 작동하게 된다. 하나는 Kernel Space 모드 이고 다른 하나는 User Space 모드이다. 이렇게 2가지 모드로 나누는 이유는 일반응용 프로그램이 시스템에 직접 접근하는 일을 막기 위함으로, 일반 응용 프로그램이 시스템에 접근하기 위해서는 System:::Call(:12) 을 불러서 Kernel 에게 시스템자원을 사용할것을 요청하는 방식으로 간접 접근해야 한다. 이때 커널은 보호모드 상태에서 System Call 을 처리해야 하므로 여러가지 연산을 가지게 되된다. 최종적으로 User 모드에서 Kernel 모드로 전환하는데 드는비용, 보호모드를 위한 여러가지 연산을 하는데 드는 비용등 3가지의 비용을 소비하게 된다.

반면 User Level 쓰레드는 대부분의 작업을 system call 을 사용하지 않고 사용자라이브러리 에서 대부분 처리하므로 Kernel Level 쓰레드가 가지는 비용을 줄일수 있다. 단점이라면 Kernel Level 쓰레드가 각 쓰레드를 보호해주는 반면 유저레벨 쓰레드는 보호를 받을수 없다는 점이다. 그러므로 유저레벨쓰레드 사용시에는 각 쓰레드를 보호하기 위한 여러가지 동기화 장치등을 사용해야 하며, 이것은 때때로 세밀하고 복잡한 코딩 기법을 요구한다.

어쨋든 현재 Unix(:12) 쪽은 Pthread 를 표준으로 가져가는것 같다.


2.1.1절. User Space쓰레드

쓰레드를 유지하기 위해서는 여러가지 정보를 필요로 한다. 이러한 정보는 "프로그램 코드", Data, Stack, File I/O, Signal 테이블 등 크게 5가지이다. User Space 쓰레드는 이러한 정보를 커널에서 관리하도록 하지 않고 쓰레드 라이브러리에서 직접 처리하게 된다. 또한 각 쓰레드간 협력이 가능하도록 switch 기능을 제공하는데, 커널쓰레드보다 일반적으로 빠른 switch 기능을 제공한다.

단점은 SMPs(Symmetric MultiProcessor system)의 장점들을 이용할수 없다는 것이다. 즉 dual 혹은 quad 의 cpu를 사용하고 있는 시스템이라 할지라도, User Space 쓰레드로는 진정한 멀티쓰레드 프로그래밍(:12)을 할수 없다는 것이다. 오직 하나의 CPU(:12)에서만 작동할수 있을뿐이다. 그러므로 설사 CPU가 2개 혹은 4개 있다고 하더라도, 수행속도차이는 그리 크지 않게 된다. 또한 하나의 쓰레드에서 I/O 봉쇄가 일어나게 되면 다른 모든 쓰레드까지 봉쇄되게 된다.

물론 이러한 문제들을 위한 해법역시 존재한다. I/O 봉쇄를 아예 라이브러리 차원에서 해결할수 있도록 도와주는 쓰레드 라이브러리도 있으며, I/O 작업을 비봉쇄 모드로 작업함으로써 봉쇄를 막을수도 있다. 그리고 몇몇의 SMPs 는 User Space 쓰레드로도 모든 SMP(:12) 자원을 이용할수 있도록 방법을 제공해 주기도 한다.


2.1.2절. Kernel Space 쓰레드

커널(:12)에서 직접 쓰레드를 관리하며, 커널자체에서 쓰레드 정보를 가진다. 또한 각 프로세스 간의 스케쥴역시 커널에서 맡는다. 이경우 I/O 봉쇄같은 문제는 신경쓰지 않아도 되며, 또한 SMPs 자원을 제대로 활용할수 있다는 장점을 가진다.


3절. Pthread 에서의 세밀한 동기화

우리는 이전의 Pthread(2) 문서에서 mutex 잠금을 이용한 데이타 동기화에 대해서 이미 알아보았다. 그러나 mutex(:12) 는 어디까지나 잠금을 위한 것으로 동기화시킬수 있는 범위는 좁은 범위로 한정되며, mutex 만 가지고는 세밀한 수준에서의 동기화는 어렵다. 그래서 mutex 와 더불어 다른 쓰레드 도구를 사용해야 한다. 이번장에서는 Condition variables (조건변수) 와 mutex 를 이용한 데이터:::동기화(:12)에 대해서 알아보도록 하겠다.


3.1절. 조건변수

뮤텍스가 잠금에 의해서 소극적인 동기화를 제공한다면, 조건변수는 "시그널 발생"과 "시그널에 대한 기다림" 을 통한 좀더 적극적인 동기화 방법을 제공한다. 이러한 시그널을 기다리기 위해서 pthread_cond_wait() 와 pthread_cond_timedwait() 2개의 함수를 제공한다. 이 함수들은 pthread_cond_signal()에 의해서 발생되는 시그널을 기다리고 있다가. 시그널이 도착하면 기다림을 멈추고 다음 루틴을 실행하게 된다. 이러한 시그널의 전달은 "조건변수" 를 통해서 이루어지게 된다. 아래는 이러한 순서를 간략하게 정리한 것이다(슈도코드형식).

임계영역에 들어간다. 
{
    요청을 기다린다.(pthread_cond_wait 를 이용해서 singal이 도착하는지 확인한다) 
    만약 요청이 도착한다면 (요청에 대한 해결이 끝날때 까지 요청영역을 임계영역으로 설정한다)
    {
        요청을 해결한다. 
    }
}
임계영역을 빠져나온다. 
			
임계영역(:12)에 진입하고 빠져나오는 것은 mutex 를 사용한다. 위의 슈도코드를 보면 단순히 잠금만을 제공하는것이 아닌, 요청/해결 의 서버/클라이언트 모델을 구현할수 있으며, 다중의 요청/해결에 대한 동기화 문제까지 해결할수 있음을 알수 있다.


3.1.1절. 조건변수 생성및 초기화

조건변수는 pthread_cont_t 의 타입으로 선언되어 있다. pthread_cond_t 는 다음과 같이 선언되어 있다.

typedef struct
{
    struct _pthread_fastlock __c_lock;  // 구조체의 잠금을 위해서 사용된다.
    _pthread_descr __c_waiting;         // 쓰레드는 이 값의 상태변화를 기다린다. 
} pthread_cond_t 
				
pthread_cont_t 의 초기화를 위한 방법은 2가지가 있다. 첫번째는 프로그램의 시작시에 선언하고 초기화 해버리는 방법과, 프로그램 실행중에 함수를 호출해서 사용하는 방법이 있다. 프로그램 시작시에 선언해서 사용하기 위해서는 다음과 같은 방법을 사용한다.
pthread_cond_t       thread_con1 =   PTHREAD_COND_INITIALIZER;
				
PTHREAD_COND_INITIALIZER 은 {__LOCK_INITIALIZER, 0} 으로 디파인 되어 있다. 위의 초기화를 사용하게 되면 pthread_cont_t 구조체를 위의 값으로 초기화 하게 된다. 또다른 방법은 프로그램 시행중에 사용하는 방법으로 pthread_cond_init() 함수를 사용하면 된다.


3.1.2절. 조건변수에 신호 보내기

우리는 조건변수(:12)에 신호를 보냄으로써, 조건변수를 (신호를)기다리는 다른 쓰레드를 깨울수 있게 된다. 보통은 이러한 신호를 보내서 깨우고자 하는 쓰레드가 하나일수도 있지만, 동시에 여러개의 쓰레드를 깨워야할 필요도 있을것이다. 다음은 이러한 시그널을 보내는 함수들이다.

int pthread_cond_signal(pthread_cond_t *cond);
int pthread_cond_broadcast(pthread_cond_t *cond);
				
pthread_cond_signal() 은 하나의 쓰레드를 깨우기 위한, pthread_cond_broadcast() 는 모든 쓰레드를 깨우기 위한 신호를 보내기 위해서 사용된다.

성공적으로 시그널이 전달되면 0이 리턴된다.


3.1.3절. 조건변수를 통한 신호 기다리기

신호를 보내는 쓰레드가 있다면, 이 신호를 받기 위해 기다리는 쓰레드도 있어야 할것이다. 신호를 받기 위해서는 pthread_cond_wait()와 pthread_cond_timewait() 두개의 함수가 사용된다. 이두개의 함수는 신호가 전달될때까지 기다리게 된다.

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);
				
첫번째 아규먼트(:12)는 신호를 기다리기 위한 "조건변수" 이며 2번째는 mutext 변수이다. 이 두개의 함수는 실행되면 mutext:::잠금(:12)을 풀고(unlock) 신호를 기다린다. 그러다가 신호가 전달되면 뮤텍스 잠금을 얻은 다음 해당영역을 실행하게 된다.

pthread_cond_wait() 와 pthread_cond_timedwait() 의 다른점은 timeout 을 기다리는지에 따라서 구별된다. pthread_cond_timedwait 는 기다림의 시간을 설정하여서 일정한 시간동안 시그널이 도착하지 않으면 ETIMEDOUT 값을 리턴한다. 반면 pthread_cond_wait 는 시그널이 도착할때까지 무한정 기다린다.

지금까지의 설명한 내용의 이해를 돕기 위해 간단한 흐름도를 그려보았다. 아래의 흐름도는 pthread_cond_wait()를 사용했을경우다.

// 뮤텍스 와 조건변수를 초기화 한다.  
pthread_mutext_t     request_lock = PTHREAD_MUTEX_INITILIZER;
pthread_cond_t       producer_cv  = PTHREAD_COND_INITIALIZER;

// 임계 영역에 대한 뮤텍스 잠금을 얻는다. 
int rc;
rc = pthread_mutext(&mutext_a);
if (rc)
{
    perror("mutext lock error "); 
    phread_exit(NULL);
}

// 조건변수 producer_cv 에 대한 시그널을 기다린다.  
// wait 에 들어가기전에 mutext 는 request_lock에 대한 잠금을 
// 얻는다. 
mutext_rc1 = pthread_cond_wait(&producer_cv,&request_lock)
if
{
    // mutext 잠금이 이루어진다.  
    // 코드 실행
}

// 뮤텍스 잠금을 돌려준다. 
pthread_mutex_unlock(&request_lock);
				

다음은 pthread_cond_timedwait()를 사용했을때의 흐름도이다. pthread_cond_wait()와 비교해서 시간설정을 위한부분이 들어가고, 타임아웃이 발생했을때 처리하는 부분이 들어가는걸 빼고는 나머지 부분은 동일하다.

...
struct timeval  now;
struct timespec timeout;
int    done;
...
rc = pthread_mutext(&mutext_a);
if(rc)
{
   ...
}

// timeout 시간 설정을 위해서 사용한다. 
gettimeofday(&now);
timeout.tv_sec = noew.tv_sec + 5
timeout.tv_nsec = now.tv_usec * 1000;

// timeout 시간동안 signal 을 기다린다. 
rc = pthread_cond_timedwait(&got_request, &request_mutext, &timeout);

// pthread_cond_timedwait 가 넘겨준 값을 이용해서 분기한다. 
switch(rc)
{
    // 시그널이 발생했을때.. 
    case 0:
        ...
        break;
    // timeout 동안 시그널이 발생하지 않았을경우
    case ETIMEDOUT:
        ...
        break;
    // 그밖의 경우(에러)
    default:  
        ...
        break;
}
pthread_mutext_unlock(&request_mutex);
				


3.1.4절. 조건 변수 없애기(Destory)

더이상 사용할 필요가 없는 조건변수는 없애주도록 하자. 이렇게 함으로써 시스템자원(:12)의 낭비를 막을수 있다. 조건변수를 없애기 위해서는 pthread_cond_destroy() 함수를 이용한다. 조견변수를 없애기 전에 조건변수를 사용하는 쓰레드가 없음을 확인해야 한다.

// 조건변수 got_request 를 삭제한다. 리턴값이 EBUSY일경우는 
// 아직 사용하는 쓰레드가 있으서 조건변수 삭제에 실패했을경우이다. 
int rc = pthread_cond_destory(&got_request);
if (rc == EBUSY)
{
    ....
}
				


4절. Thread-Specific Data

4.1절. 쓰레드간 전역변수 사용의 문제점

일반적인 단일 쓰레드:::프로그래밍(:12)을 할때, (비록 권장하지는 않지만) 전역변수(:12)를 사용하는 경우가 종종 있을것이다. 전역변수를 씀으로써 그렇지 않을때 보다 코드를 훨씬 쉽게 기술할수도 있기때문이다.

멀티쓰레드:::프로그램(:12)에서도 이러한 전역 변수가 필요할때가 있다. 그런데 전역변수를 쓰는데 약간의 문제가 발생한다. 이유는 모든 쓰레드가 전역변수를 공유해 버리기 때문에, 쓰레드별 전역변수를 사용할수 없기 때문이다. fork() 를 이용한 멀티:::프로세스(:12) 모델에서는 프로세스간 전역변수 공유가 되지 않기 때문에, 각 프로세스 개별적인 전역변수를 사용할수 있는것과는 대조적이다.

그럼 어떻게 해야지 쓰레드 개별적으로 전역변수를 사용하게 할수 있는지 알아보도록 하겠다.


4.2절. Thread-Specific Data

4.2.1절. Thread-Specific Data 의 개념

이러한 문제의 해결을 위해 등장한것이, Thread-Specific Data (이하 TSD)이다. 같은 전역변수가 서로 다른 메모리 영역을 가르키게 하는 방법을 사용하는데, 다른 메모리 영역의 주소를 가리키는 각각의 다른 key 를 사용함으로써, 쓰레드간 개별적인 전역변수를 엑세스하게끔 만들어준다.

이것은 간단한 데이타베이스 형태인 key-value 관계로 나타낼수 있는데, 각각의 key 에 이름을 부여하고 이 key 가 value 를 가리킨다. 이 value 는 메모리 영역이 될것이다.

+-----------------------------------+
| Process                           |
|                                   |
|     Global_data                   |
|     +-------+-------+-------+     |
|     | data1 | data2 | data3 |     |
|     +-------+-------+-------+     |
|     ^       ^       ^             |
|     |       |       |             |
|     |       |       |             |
|    key1    key2    key3           |
|     |       |       |             |
|   +---+   +---+   +---+           |
|   |   |   |   |   |   |           |
|   | A |   | B |   | C |           |
|   +---+   +---+   +---+           |
+-----------------------------------+
				
위의 그림은 쓰레드 A, B, C각 하나의 전역변수인 Global_data 에 어떻게 자신만의 전역데이타를 읽고 쓸수 있는지에 대한 개념을 나타낸것이다.


4.2.2절. TSD 블럭의 할당(생성)

pthread_key_create() 함수를 이용해서 모든 쓰레드에서 효력을 가지는 새로운 key를 할당받을수 있다. 최초에 key 를 만들게 되면 이 key 는 기본적으로 NULL을 가르키게 된다. 나중에 쓰레드는 이 key 값을 변경하게 됨으로써 자신이 원하는 메모리 영역을 참조할수 있게 된다. 다음은 이 함수가 어떻게 사용되는지에 대한 간단한 예이다. pthread_key_t 는 unsigned int 형이다.

int rc;
pthread_key_t list_key;

// clean_list 는 사용자 정의 함수로, 나중에 데이타가 필요없을때 
// 데이타를 제거(free) 하기 위해서 필요한 함수이다. 
extern void* clean_list(void*); 

// key 를 생성하며 데이타 제거를 위한 함수를 지정해준다. 
// cleanup_list 함수는 NULL 로 지정될수도 있으며, 
// 이경우 나중에 key 를 삭제하더라도 데이터가 제거되지는 않는다. 
rc=pthread_key_create(&list_key, cleanup_list);
				
pthread_key_create()를 실행한후에 list_key 는 새로 만들어진 key 를 가르킨다. pthread_key_create 는 성공적으로 실행될경우 0을 반환하고 그렇지 않을경우에는 적당한 에러코드를 반환하도록 되어있다. 생성할수 있는 key 의 숫자는 제한되어 있는데, 생성할수 있는 최대크기는 PTHREAD_KEYS_MAX 에 정의 되어 있다. 이값은 OS 마다 다를수 있으며 보통 1024 의 크기를 가진다.


4.2.3절. TSD 블럭 에 대한 Access

key 를 만들었다면 이제 value 에 엑세스를 해야 한다. 엑세스를 위해서 pthread_getspecific()와 pthread_setspecific()두개의 함수가 제공된다. 첫번째 함수는 key 에 대한 value를 가져오기 위해서 사용되며, 두번째 함수는 key 에 value 를 세팅하기 위해서 사용된다. value 는 (void *)형으로 원하는 어떤 데이타라도 넘길수 있도록 되어있다. 다음은 간단한 사용 예이다.

    
phtread_key_t a_key;
int rc;

int *p_num = (int *)malloc(sizeof(int));
(*p_num) = 4;

rc = pthread_setspecific(a_key, (void *)p_num);
...
// 만약 a_key 에 대해서 p_num 값을 가져오고 싶다면
{
   int *p_keyval = (int *)pthread_getspecific(a_key);

   if (p_keyval != NULL)
   {
      printf("value of 'a_key' is: %d\n", *p_keyval);
   }
}
				


4.2.4절. TSD 블럭 삭제

더이상 사용할 필요가 없는 TSD 블럭은 pthread_key_delete()를 이용해서 삭제한다. 주의 할것은 이것은 key 를 삭제하는 것이지 실제 데이타의 메모리를 삭제하지는 않는다는 것이다. 데이타 메모리의 삭제는 pthread_key_create() 로 key 를 만들때 지정한 데이타 삭제 함수가 이용된다. 만약 데이타 삭제 함수가 NULL 이였다면 데이타 삭제는 일어나지 않을것이다.

int rc = pthread_key_delete(key);
				


5절. 결론

지금까지 Pthread 에 대한 몇가지 이슈들을 살펴보았는데, 여전히 다루지 못한 사항들이 있습니다. 그리고 실제로 어떻게 응용이 가능한지에 대한 방향제시도 좀 미약하구요. 이러한 부족한 점들은 나중에 다루게 될 "다중 연결 서버구성"의 쓰레드 편을 다루면서 보강하도록 하겠습니다.

이 문서들은 인터넷상의 온라인문서들과 man 페이지들을 참고해서 만들었읍니다. 그리고 제 스스로 쓰레드에 대해서 그리 깊은 지식을 가지고 있지 않음으로, 잘못된 내용이 있을수 있습니다. 이러한 내용은 게시판 등 에댓글을 남겨주시면 수정하도록 하겠습니다.