OS

Go back

OS Review
Device Driver
NS Tools

Home
Papers
Daily Link

To Main

15. 쓰레드 그리고 끝내며 (Thread and The Epilogue)

정말 살다보니 이거 마지막회 쓸 날이 오긴 오네 그랴,,, 여러분들 그동안 이거 읽기 드럽게 힘들었죠? 유종의 미를 거두기 위해서 더퍼군 오늘또한 최선을 다해 최대한 좋은 글을 남기기를 다짐하며 오에스론의 마지막 논의를 열어보겠습니다. 이번장의 주인공은 쓰레드(thread)입니다. 쓰레드!!!

쓰레드는 현대적인 오에스를 논함에 있어서 반드시 없어서는 안될 존재처럼 많은 이들이 호들갑을 떨고는 하지요. 하지만 도처에 등장하는 쓰레드의 제대로 된 개념을 일부라도 알고 있는 이들은 의외로 드물다는 사실은 오히려 놀랍기 조차 합니다. 쓰레드가 책에서는 프로세스가 소개되는 장에서 등장을 하게됩니다. 그만큼 프로세스에 대한 확실한 이해가 선행되어야 한다는 이야기겠죠? 그부분 건너 뛴분들 앞으로 펼쳐질 내용은 프로세스와 쓰레드의 차이점을 기준으로 논하느니만큼 프로세스부터 공부하고 보시기 바랍니다. 프로세스는 자신이 사용하는 리소스와 실행이 되고있는 장소에 의해서 정의될수 있으며 차일드 프로세스가 생성될시에는 패런트 프로세스로 부터 모든 변수및 상태를 로컬로 복사해온뒤 사용을 하게 된다고 설명했던 적이 있습니다. 또한 이때 프로세스간에는 글로벌 변수란 의미가 없어지기에 특별히 공유 메모리(shared memory), 세마포어(semaphore), 그리고 메시지(message)같은 IPC(Inter Process Communication)를 이용해서 프로세스 사이의 통신이라는 개념으로 변수를 결과적으로 공유하게 된다고 했을겁니다. 여기까지 기억하는 당신,,,정말 멋져보이오,,,

만일 우리가 새로운 프로세스의 생성을 위해서 fork()라는 시스템콜을 이용했을때 위와 같은 새로운 프로세스의 생성과정과 달리 새로운 프로그램 카운터(다음 실행할 명령어가 들어있는 주소의 시작을 담고 있습니다)와 자신의 컨트롤만을 가지고 이미 존재하고 있는 프로세스의 주소공간을 모두 공유!하고 있는 그 무언가가 등장한다고 가정해본다면, 이는 정말 유용한 기법이 될듯하지 않나요? 그렇습니다. 바로 그 무언가가 쓰레드의 정체인 것이죠. 쓰레드는 이와같이 프로세스와 사뭇 유사한 개념을 가지고 있으면서도 확실히 다른 면모가 있기 때문에 종종 홀쭉이 프로세스(lightweight process-LWP)라고도 불리게 됩니다. 홀쭉이라는 것은 결국 부모의 프로세스로부터 어쩔수 없이 물려받아 새로이 할당해야만 했던 주소공간을 그냥 직간접적으로 공유해버리는 속성으로부터 나온 말이겠죠. 쓰레드를 이루는 구성요소는 따라서 프로그램카운터, 레지스터셋, 그리고 스택공간등이며 동료쓰레드(peer thread)들과는 코드섹션과 데이터색션, 그리고 태스크(task)로 총칭되는 시스템리소스를 싸그리 공유!하게 됩니다. 전통적인 프로세스는 다른말로 뚱땡이 프로세스(heavyweight process)라고 불리게 되고, 뚱땡이에게는 정확히 하나의 쓰레드에 하나의 태스크가 대응이 되지요. 그렇게 주소공간을 공유함으로써 얻는 이익은 그렇다면 무엇일까요? 가장 눈에 띄는 장점으로써는 쓰레드는 프로세스와 달리 일단 생성시 그리 부하가 걸리지 않습니다. 로컬 메모리 할당을 추가적으로 하지 않으니까요. 또한 쓰레드간의 전환시 레지스터 수준에서의 스위칭이 필요하기는 하지만 프로세스간에 전환하면서 일어나는 컨텍스트 스위칭(context switching)에 비해서는 메모리 관리에 관련된 작업이 거의 일어나지 않으므로 신속한 전환이 가능하겠죠.

쓰레드를 시스템에서 구현할때에는 크게 두가지 방법을 사용하게 됩니다. 오에스 커널 수준에서 직접 구현하는 방법과 유저레벨(user-level)에서의 인스톨인데 후자는 직접적인 시스템 콜을 이용하지 않고 쓰레드에 관련된 라이브러리를 이용하게 됩니다. 매킨토시 시스템 확장파일중에도 쓰레드 매니저라는것을 예전에 본 기억이 있을겁니다 이것이 바로 위에서 언급한 라이브러이이죠. 따라서 유저레벨 쓰레드의 경우는 쓰레드간의 스위칭시 오에스로의 시스템콜을 날리지 않기에 커널 수준에서의 인터럽트 또한 발생하지 않는 장점을 가지고 있지만, 커널자체가 단일 쓰레드로 이루어져있는 경우 유저레벨에서 특정 쓰레드가 시스템콜을 할때 그 콜이 리턴될때까지는 다른 쓰레들은 마냥 기다리기만 해야한다는 단점또한 가지고 있어요. 이것은 결과적으로 공평하지 못한 시피유 스케줄링을 초래하게 됩니다.

쓰레드는 또한 여러면에서 프로세스와 행동하는 양식이 같습니다. 예를들어 프로세스와 같이 준비, 막기, 실행, 그리고 종료의 상태를 가지고 있고 부모 쓰레드가 차일드 쓰레드를 생성시킬수 있으며 쓰레드들간에 씨피유를 공유하기는 하지만 막상 한개의 쓰레드만이 한번에 실행될수 있게되지요. 하지만 프로세스와 달리 쓰레드는 각각이 독립적으로 존재하는것이 아닙니다. 관련된 쓰레들끼리는 태스크에 대한 모든 주소값에 접근이 가능하고 심지어는 서로의 스택값까지도 침범할수 있는 권한이 주어지게 되지요. 따라서 쓰레드 사이에서의 싱크(Synchronization)문제는 참으로 중요하다는 사실은 두말하면 잔소리고 세말하면 입만아픈겁니다.

자, 그렇다면 과연 쓰레드에 대한 개념이 조금이나마 뚜렷해 지시나요? 다음의 프린터 서버 예를 통해서 같은 기능을 쓰레드와 프로세스로 구현했을때의 차이점을 확실하게 알아둡시다. 우리가 최대 3대의 클라이언트와 동시 접속이 가능한 네트웍 프린터 서버를 한개 만들어야하는 상황에 놓여있다고 칩시다. 네트웍 서버는 동시에 여러명의 클라이언트가 접속을 한다는 특징을 가지고 있기에 직관적으로 여러개의 프로세스 또는 쓰레드가 필요할것이라는것은 자명해지죠. 참고로 밑의 예에서는 쓰레드의 구현을 위해서 쓰레드 라이브러리로는 가장 널리 쓰이는 POSIX(Portable Operating System Interface) pthread를 사용한다는것을 전제로 하겠습니다.

1. 멀티 프로세스를 이용할경우 : 일단 누군가가 접속을 요청했는지를 언제나 감시하고 있다가 요청이 들어오면 재빨리 프로세스 한개를 fork() 시킵니다. 이때 fork된 프로세스의 부모 프로세스는 나름대로 프린팅에 필요한 모든 준비가 되어있기에 fork된 차일드 프로세스 또한 부모와 똑같은 능력을 갖추고 태어나게 됩니다. 만일 동시에 또하나의 클라이언트가 요청을 하게 되면 또한번의 fork로써 간단하게 연결을 물려주게 됩니다. 하지만 최대 3대의 프린터를 공유할수 있다는 전제가 있기때문에 현재 제공이 가능한 프린터의 갯수를 프로세스들이 서로 트래킹을 해야하겠죠. 이때 사용할수 있는 도구가 바로 공유 메모리가 되겠죠. 즉, 부모 프로세스가 abcde라는 변수들을 가지고 있다면 첫 차일드 프로세스는 a'b'c'd'e' 라는 변수를 생성시키고, 두번째 차일드 프로세스는 a''b''c''d''e''라는 변수를 생성시키죠. 거기다 프린터 갯수의 트래킹을 위해 f라는 글로벌 변수를 별도로 공유메모리로 잡아놓고 쓰게되는 것이죠.

2. 멀티 쓰레드를 이용할경우 : 먼저 POSIX pthread를 쓰기위한 각종 준비를 한뒤,누군가의 접속에 대한 요청을 감시하기까지는 위와 동일한 루틴이 사용됩니다. 하지만 요청이 들어오면 pthread_create()이라는 함수를 사용해서 쓰레드를 생성시켜주게 되죠. 그리고 쓰레드 별로 위와 똑같이 각 클라이언트마다 한개씩 맞물려 주게 되는데, 여기서 주목해야 할 차이점은 바로 쓰레드는 생성시 쓰레드를 생성시킨 프로세스가 가지고 있던 abcde에 대응되는 a'b'c'd'e'를 만들지 않는다는 점이죠. 고로 아무리 쓰레드를 만들어 내어도 abcde외에는 생기지 않습니다. 또한 위에서 트래킹을 위한 변수 f가 공유변수의 형태로 필요했듯이 여기서도 f가 필요하겠지만 여기서는 공유변수로 존재할 이유가 없어집니다. 왜냐면 모든 쓰레드는 어차피 자신을 생성한 프로세스의 로컬및 글로벌 변수에 대한 접근이 허용되니까요. 하지만 싱크문제를 조심해야 한다고 했죠? 그렇게 때문에 뮤텍스, 그리고 조건변수에 대한 세마포어라 할수 있는 pthread_cond_signal 과 pthread_cond_wait을 통해 단 한번에 한개의 쓰레드만이 f라는 변수를 접근할수 있도록 허용해주어야 안전하게 트래킹이 됩니다.

위에서 제시한 예제는 제 홈페이지에 있는 Assignment8 part1과 part2이니 만큼 관심있으신 분은 한번 소스코드를 분석해보시기 바랍니다. 이처럼 쓰레드는 프로세스 내에서 무엇인가를 구현하기 위한 매우 효과적인 수단인것이지 차일드 프로세스로 구현하지 못하는 그 어떤것을 해내는 새로운 존재가 아닌것입니다. 한개의 프로세스내에 또다른 여러개의 프로세스를 넣을수도 있고, 여러개의 쓰레드로 채울수도 있고는 바로 프로그래머의 재량인것이죠. 이상으로 쓰레드에 대한 설명을 마치도록 하죠.

제 욕심으로는 OSI 7 레이어 프로토콜또한 간략하게 설명하는것이 계획이었으나, 사실 여기서 설명을 하기에는 각각의 레이어를 나열하는것 이상의 설명이 불가능할듯 하군요. 더구나 이 내용은 직접적인 오에스적인 관점보다는 통신공학적인 관점에서 설명하는 것이 더욱 적절할듯 합니다. 참로로 전자공학이나 통신공학 학부3학년 과정에서는 본 내용을 한학기 내내 다루게 되지요. 고로 본 내용은 추후에 인터넷의 표준인 TCP/IP에 대한 논의와 함께 미래에 좀 다른 시각에서의 접근을 모색하기로 본인은 결정을 내렸습니다. 음,,,아무도 불만이 없군요. -_-

글을 맺으며.
그동안 제 어줍잖은 장황한 설명문 읽으시느라고 여러분 수고가 많으셨네요. 솔직히 고백하건데 전 이번 기회를 통해서 코끼리의 꼬리, 발, 이빨,,,이런식으로만 알고 있던 그림들이 거대한 코끼리의 형상으로 제 머리속에 각인되는 좋은 경험을 하게 되었습니다. 우리가 막연히 어렵다고 여기고 있는 많은 것들이 문자의 해독이라는 지겨운 작업을 거쳐서 머릿속에 개념으로서 자리잡게 되면 참으로 어이없을만큼 단순하고 상식선의 연장이었다는 사실을 공부를 계속 하면서 느끼게 됩니다. 지금 저희들은 수많은 퍼즐들을 머릿속에 넣고 있다고 생각해요. 언젠가 그 퍼즐들은 어떤 계기에 의해서든지 제 자리를 찾아가게되고 결국에는 웅장한 형상을 드러내는 날이 올것이라 저는 믿습니다. 비록 일부밖에는 현재 보이지 않고 넣는 작업 자체가 힘겨울때도 많지만, 뭔가를 모르는자는 아는자의 그 기쁨을 결코 이해하지 못할듯 싶습니다. 희망을 가지고 공부할수 있기를 소망합니다.

추신. 저의 글속에는 분명이 알게 모르게 오류가 있을것입니다. 그것을 바로잡아주시는 분들께 더없는 고마움을 미리 전합니다.

제 사랑하는 아내 정민에게 이 글을 바칩니다.
1999. 7. 11 오후 11시 28분.
클리브랜드에서

-duffer 경준 (http://vorlon.cwru.edu/~kxm73)