3. Processes and Threads

Process

프로세스의 논리적 정의는 "실행중인 프로그램" 이다.

그리고 그 실체는 프로그램이 실행되기 위해서 필요한 모든 정보들을 담고 있는 자료구조다.

Branch나 Jump에 의해서 프로그램이 sequential하게 수행되는 패턴이 바뀔 수는 있지만, 브랜치나 점프가 없다면 프로그램은 기본적으로 순차적으로 수행된다.

 

프로세스 안에는 어떤 내용들이 담겨 있을까?

Text Section: 프로그램의 코드가 담겨 있는 영역

Stack Section: Function Call과 Context Switch를 위한 정보가 저장되는 영역

- Function Call: 함수가 중첩되어 호출되게 된다면, A함수에서 B를 호출하고 B함수에서 C함수를 호출한다고 해보자. return 주소를 중심으로 생각해보면, C함수가 끝나고 나면 B함수로 돌아가야 하는데, 그러려면 B의 주소를 알아야 한다. Stack에 return address를 저장한다면 C함수가 끝난 후 pop하면 B로 가는 return address를 쉽게 꺼낼 수 있다.
=> 그래서 function call 관련 정보들은 stack에 담는 것이 좋다.

- Context Switch: 수행 중이던 프로그램의 PC를 포함한 레지스터 정보, Stack pointer의 주소 등을 저장한다.

Data Section: 현재 프로그램의 어느 부분을 수행하든지 상관없이 접근할 수 있는 데이터인 Static 변수나, 전역 변수에 관련된 데이터를 저장한다.

Heap Section: 동적 할당된 메모리들은 힙 영역에 할당된다.

 

프로세스가 메모리에 탑재될 때 어떤 모습으로 탑재가 되는가

프로세스가 사용할 수 있는 메모리 공간을 Address Space라고 한다.

각 프로세스는 logical하게 연속된 공간을 할당받는다. 그런데 logical하게 연속된 공간이지 physical하게는 연속된 공간이 아닐 수도 있다. 각 영역은 실제 메모리에는 따로 떨어져서 저장되어 있을 수 있다.

이건 가상 메모리를 사용하기에 가능한 것이다. 각 프로세스에게 연속된 가상 메모리 주소를 할당해주고, 가상 메모리 주소는 실제 메모리 주소와 매핑이 되어 있다.

가상 메모리 주소 상으로는 연속되어 있지만, 매핑된 실제 메모리 주소는 연속적이지 않을 수 있다.

 

Address Space의 영역 중에는 고정된 크기의 영역이 있고, 가변 크기의 영역이 있다.

프로그램 코드와 전역 변수가 저장된 text, data 영역은 고정 크기 영역이고,

function call, context switch를 위한 정보가 저장된 stack과 동적 할당이 되는 heap 영역은 가변 영역이다.

stack은 function이 호출되고 return될 때마다 늘어나고 줄어드니까 가변 영역.

heap은 사용자가 메모리를 동적으로 할당하고 해제할 때마다 늘어나고 줄어드니까 가변 영역.

=> 그래서 고정 크기 영역을 아래에 쌓고, 가변 영역인 heap과 stack을 위에 쌓음.

 

그림을 보면 heap과 stack은 서로 반대 방향으로 자라난다. 이렇게 하면 heap과 stack이 만나지만 않으면 문제 없이 사용될 수 있다.
그런데 logical하게 연속된 공간이기 때문에 max가 사실 엄청나게 큰 값이다.
=> 둘이 만날 일이 없다. 

 

Process State

프로그램이 수행됨에 따라 프로세스의 상태는 수시로 바뀐다.

new: 프로세스가 메모리에 탑재는 되었지만, CPU 스케줄링 대상에 등록이 되지 않은 상태.

프로세스가 메모리에 올라왔으면 CPU 스케줄링할 때 포함하면 되지 왜 new 상태로 두느냐?

일반적인 시스템에서는 프로세스가 new 상태로 머무는 경우가 거의 없음. 그런데 실시간 시스템에서는 각 작업의 deadline이 보장되어야 함. 현재 돌고있는 프로세스들이 deadline을 지키면서 잘 돌고 있는데, 새로운 프로세스가 들어오면 이 프로세스에 자원이 할당되어야 한다. 자원을 나눠주게 되면 기존의 나머지 프로세스들이 deadline을 만족시키지 못 할 수도 있음.
=> 실시간 시스템에서 deadline을 지키지 못 하는 것은 심각한 문제임. 그렇기 때문에 새로 만들어진 프로세스에게 자원을 나눠주기 전에 나눠줘도 기존의 프로세스들이 deadline을 지키는 데에 큰 문제가 없는지 먼저 판단.
=> 만약 새 프로세스에 자원을 나눠주게 되면 기존의 프로세스가 deadline을 지키지 못 하게 될 것 같으면 새로운 프로세스는 new 상태로 둔다.
=> 기존의 프로세스 하나가 끝이 나면 새 프로세스를 등록해주거나 그렇게 한다.

running: 프로그램이 CPU를 받아 실제 수행되고 있는 상태

=> 만약 CPU 코어가 하나라면 running 상태의 프로세스는 하나만 존재할 것이다.

waiting: Event가 끝나기를 기다리는 상태. 여기서 이벤트는 대부분 I/O 이벤트를 말한다.

즉, I/O가 끝나기를 기다리고 있는 상태. I/O 장치로부터 Interrupt를 받으면 wating 상태에서 벗어나게 된다.

ready: CPU를 할당받기를 기다리고 있는 상태

wating과 ready는 일을 하지 않고 있다는 점에서는 동일하지만, waitng은 I/O가 끝나야지만 CPU를 받을 수 있고 ready는 언제든지 CPU를 받을 준비가 되어 있는 상태라는 점에서 다르다.

terminated: 모든 Instruction을 수행해서 프로그램이 종료가 된 상태. 더 이상 CPU 스케줄링 대상에 포함되지 않는다.

 

running 상태에서 벗어나는 상황은 3가지가 있다.

1. 마지막 Instruction을 수행해서 프로그램이 종료가 되는 시점에 exit을 통해 terminated 상태로 바뀜
2. 프로세스 수행 도중에 I/O가 발생한 경우 CPU를 놓고 waiting 상태로 간다.
=> Interrupt를 받으면 다시 ready 상태로 간다
3. 이 프로세스한테 할당된 시간이 끝나서 다른 프로세스에게 CPU를 넘겨줘야 할 때.

그림에서 보면 Interrupt를 받았다고 되어 있다. Timer라는 디바이스가 시간이 종료되었다는 Interrupt를 보냄. 그럼 CPU 스케줄러가 이 프로세스는 Ready 상태로 보내야겠다 판단하고 Ready 상태로 보냄

 

Process Control Block(PCB)

프로세스에 대한 자료구조.

현재 수행 중이거나 수행되기를 기다리는 프로세스들의 정보를 저장하고 있는 자료구조다.

현재 PC값은 어디를 가리키는지, PCB가 어디에 올라와 있는지, 레지스터에는 어떤 값이 들어있는지, heap과 stack은 얼마나 늘어나 있는지 등의 정보를 저장함.

 

이러한 PCB 정보는 Context Switch를 할 때 사용된다.

P0 프로세스를 실행하다가 Time Interrupt가 발생하거나 프로세스 내에서 System Call을 호출하면 P0는 잡고 있던 CPU를 다른 프로세스에게 넘겨줘야 한다.

그러면 현재 P0 프로세스의 상태를 PCB 형태로 저장한다. 그리고 새롭게 수행할 프로세스 P1의 PCB 정보를 load해서 P1를 수행할 수 있도록 세팅한다. PC값 세팅하고, 레지스터에 값을 다시 불러오고,, 등등

 

Process Scheduling Queues

OS가 관리해야 할 프로세스들이 한 두 개가 아닐 것임. CPU를 기다리는 프로세스들도 있을 것이고, CPU를 사용하고 있는 프로세스, 또는 I/O로 인해서 waiting 상태에 있는 프로세스들 까지.

이런 프로세스들이 그냥 뒤죽박죽으로 있다면 OS가 다음에 CPU를 줄 대상 프로세스를 찾는 것이 번거로울 것이다.

그래서 상태별로 프로세스를 queue에 모아둔다.

1. Job Queue: 시스템 내의 모든 프로세스를 가지고 있는 큐

2. Ready Queue: CPU를 기다리는 ready 상태의 프로세스들이 모여있는 큐.

=> OS가 CPU를 줄 대상을 정할 때 Ready 큐에 있는 프로세스 중 고를 것임.

3. Device Queue: I/O Device를 기다리는 프로세스. 즉, wait 상태에 있는 프로세스들이 모여있는 큐

 

상태가 변하면 Queue -> Queue로 프로세스가 이동한다.

큐에 있는 프로세스들 중 어떤 프로세스의 상태를 바꾸고 다른 큐로 옮길지 선택하는 역할을 하는 것이 Scheduler이다.

큐간의 이동이 발생하는 주기에 따라 long-term, short-term, mid-term 스케줄러로 나눌 수 있다.

 

Long-term scheduler( or job scheduler )

: 프로세스가 새로 생성되었을 때 생성된 프로세스를 대상으로 기존의 프로세스가 하나 빠져나가면 새로운 프로세스를 집어넣는 역할이기 때문에 자주 발생하지는 않는다( Long-term ).

new 상태의 프로세스를 ready 상태로 만들고 ready queue에 넣어주는 역할

 

Short-term scheduler( or CPU scheduler )

: Ready 상태의 프로세스 중 어떤 놈에게 CPU를 줄지 결정하는 역할이기 때문에 매우 자주 발생( Short-term ).

또한 I/O가 끝난 프로세스를 Device queue에서 Ready queue로 옮기는 것 역시 Short-term scheduler의 역할이다.

 

Midium-term scheduler

: 멀티 프로그래밍을 하다 보면 많은 프로그램이 동시에 돌아가게 되어 메모리를 확보해야 하는데, 메모리가 부족할 수 있다. 그러면 메모리를 차지하고 있는 여러 프로세스 중 하나를 골라서 디스크로 내리고(swap out) 새로운 프로세스를 집어 넣는다(swap in).
어떤 프로세스가 일을 하다가 swap out이 되면, swap out된 상태로 있다가 이놈이 다시 CPU를 잡아야 될 시점이 오면 다시 메모리로 가지고 와서 Ready 큐에 넣어준다.
어떤 프로세스를 swap out시켜서 CPU를 주지 않는 상태로 바꿔주고 다시 CPU를 잡아야 할 시점이 오면 다시 디스크에서 읽어서 메모리에 올린 다음 Ready 큐로 보내주는 일을 하는 애가 Medium term scheduler.

어떤 프로세스가 swap out될까?

사용자가 Ctrl + Z를 눌러서 suspend 상태가 된 애들은 swap out을 시킬 아주 좋은 대상.
주로 suspend 상태의 프로세스가 swap out 대상이 되더라.

 

Long-term scheduler는 Degree of multiprogramming을 관리하는데

Degree of multiprogramming이란 CPU 스케줄링의 대상이 되는 프로세스의 수를 말한다. Long-term scheduler가 새로운 프로세스를 CPU 스케줄링 대상에 편입시키면 Degree가 1 증가한다.

스케줄링의 효율성을 위해 프로세스의 종류를 2개로 나눠서 관리한다.
I/O를 많이 발생시키는 프로세스냐, I/O는 발생시키지 않고 계산을 많이 하는 프로세스냐.

이게 CPU 스케줄링할 때 아주 중요한 정보가 된다.

 

I/O bound process

편집기, 메신저 사용자가 입력을 많이 하는 프로세스들.

사용자의 입력을 계속 받다가 사용자가 뭔가 탁 누르면 그때만 잠시 CPU를 받아서 일을 한다.

CPU를 한 번 사용할 때 매우 짧게 사용함.

CPU 사용 빈도 ↑, 1회당 사용 시간 ↓

 

CPU bound process

I/O는 거의 발생하지 않고 계산을 많이 하는 프로세스들.

CPU-bound process는 한 번 CPU를 받으면 최대한 사용하려고 함. I/O가 발생하지 않으니까.
CPU 사용 빈도 ↓, 1회당 사용 시간 ↑

---

Context Switch

기존 수행 중이던 프로세스의 문맥을 완전히 새로운 프로세스의 문맥으로 전환하기 때문에 Context Switch라고 한다.

현재 CPU를 잡고 있는 프로세스에서 다른 프로세스에게 CPU를 넘겨주는 과정이라고 생각하면 됨.

그러기 위해서는 현재 수행 중인 프로세스의 정보를 PCB의 형태로 메모리에 저장해 두고, 다음으로 수행할 프로세스의 PCB를 메모리에서 로드해서 프로세서를 세팅.

기존 프로세스 정보를 저장하고, 메모리에서 수행할 프로세스의 정보를 가져와서 세팅을 해야 하므로 오버헤드가 발생한다.

Context Switch는 멀티 프로그래밍을 지원하는 OS라면 감내해야 할 오버헤드이다.

 

Context Switch를 함에 따라 부가적으로 발생되는 오버헤드가 있는데, 바로 Cache flushing 이다.
캐시에는 현재 CPU가 프로그램을 수행하는 과정에 메모리에서 읽어들인 데이터가 캐시에 올라온다.

즉, 현재 수행중인 프로그램의 메모리 데이터의 일부가 저장되는 것.
그런데 Context Switch가 발생하면 새로운 프로그램이 실행되고 기존의 캐시에 저장되어 있는 이전 프로그램의 문맥(instruction과 데이터)은 필요가 없어짐.
그래서 Context Switch가 발생하면 캐시를 아에 비워버린다(Cache flushing). 그리고 나서 새로운 프로그램을 실행하면 캐시가 비어있기 때문에 초반엔 무조건 cache miss가 매우 자주 발생함.

=> Context Switch가 동반하는 오버헤드

---

Process Creation

만약 사용자가 프로그램을 더블 클릭해서 실행 하게 되면 Process가 만들어지게 되는데, 이 프로세스를 만드는 주체는 누구일까. 더블 클릭을 하는 주체는 사람이긴 하지만 사람이 프로세스를 만드는 건 아니니까 누군가 하고 있을 텐데 누구일까.

유저가 더블클릭을 하게 되면, User Interface를 관장하는 프로세스가 더블 클릭 이벤트를 받아들여서 Fork()를 호출해 줌.

또는 터미널에서 명령어를 치고 엔터를 누르면, 사용자 명령을 받아들이는 프로세스인 Shell process가 키보드 input을 받아 들여서 Fork()를 호출.

결국 프로세스를 Create하는 주체는 프로세스임.

프로세스가 프로세스를 만들고 연쇄적으로 프로세스가 프로세스를 만드는 것이다.

=> 그래서 프로세스들 간의 가계도가 존재.
부팅을 하게 되면 루트 프로세스가 만들어지고 루트 프로세스가 Init 프로세스를 생성. Init 프로세스가 Shell 프로세스를 비롯해 여러 프로세스들을 Fork한다. 그리고 또 그 프로세스들이 또 다른 프로세스를 Fork,,,

Linux Process Hierarchy

 

어떻게 이 많은 프로세스들을 구분하고 관리할까?

모든 프로세스는 고유한 프로세스 ID를 가진다. 이 pid를 가지고 모든 프로세스를 구분.

 

프로세스가 프로세스를 만드는 방식으로 프로세스가 만들어지기 때문에 부모 프로세스와 자식 프로세스 존재.

• Resource Sharing

자식 프로세스는 부모 프로세스와 완전히 동일하게 Address Space가 구성이 되는데, 그럼 자원도 공유할까?

Parent 프로세스와 Child 프로세스 사이에는 사실 내용적인(Context) 측면으로는 아무 관계가 없음.
그렇다 하더라도 관계를 관리하는 이유는  자기 자식의 프로세스가 죽었을 때 리턴 값을 누군가는 받아야 하는데 받아주는 사람이 없으면 output값은 없어지는 것임. 그 역할을 부모 프로세스가 한다.

부모와 자식 사이가 내용적으로도 매우 밀접한 경우도 있긴 하다.

웹 서버를 생각해보면, 누군가 웹 서버에 접속했을 때 웹 서버는 자식 프로세스를 하나 만들어서 request를 처리하게 만든다. (실제론 프로세스가 아닌 스레드가 만들어지지만 일단 프로세스라 생각하자)
http request가 올 때마다 프로세스를 만들어서 request를 처리.
웹 서버가 만든 자식 프로세스는 그 웹 서버 프로그램의 코드를 실행하는 프로세스다.

결국 두 개의 프로세스는 똑같은 코드지만 다른 부분을 수행하고 있는 것이다.
즉, text 부분은 완전히 똑같지만 PC가 가리키는 위치만 다른 것.
=> 매우 밀접한 관계를 가진다.
=> 이러한 경우에는 자원을 공유하는 경우도 있음.

부모 자식 간에 자원 전체를 공유할 수도 있고 일부만 공유할 수도 있고, 아무런 관계가 없는 경우 공유를 안 할 수도 있음.

 

• Execution

부모와 자식 프로세스는 동시에 수행되는 것이 원칙.
그런데 어떤 경우에는 부모가 자식을 Fork 시켜놓고 부모는 wait. 그리고 자식이 종료되어 return 값이 올 때까지 기다린다. return 값이 오면 깨어나서 return 값을 처리해 주는 관계가 존재할 수도 있다.

 

• Address Space

프로세스가 Fork되어 새로 만들어지면 새로 만들어진 프로세스의 Address space(자료 구조)에는 무슨 내용이 채워질까.
기본적으로 Fork가 되면 부모 프로세스의 Address space를 그대로 카피하는 게 디폴트.

=> Fork가 호출되는 시점에는 Child 프로세스가 어떤 내용을 수행할지 모르기 때문에 일단 부모 프로세스의 내용을 모두 복사한다.
별도의 프로그램을 수행할 프로세스라는 것이 결정이 나면 그때서야 별도의 프로그램으로 내용을 채우게 된다.

 

• UNIX

이 과정을 UNIX를 기준으로 예를 들어보자.

UNIX에서는 새로운 프로세스를 만들어서 부모 프로세스의 Address space를 그대로 복사하는 것까지가 fork() system call에 해당하는 내용.
=> 이때까지는 부모 프로세스와 자식 프로세스는 완전히 동일한 내용

exec() system call을 호출해야 인자로 넘겨준 프로그램 이름을 통해 그 프로그램의 Context로 자식 프로세스의 Address space를 채우게 된다.
=> 부모 프로세스와 완전히 독립적인 프로세스가 만들어짐

 

그런데 여기서 의문점. 

fork system call이 호출된 직후엔 부모 프로세스와 자식 프로세스가 완전히 동일하다고 했다. 그러면 이 두 프로세스를 어떻게 구분할까. 부모 프로세스의 Address space를 그대로 복사했으니 PC 값, 레지스터 상태까지 같은데, 어떻게 구분을 해서 자식한텐 이걸 시키고 부모는 계속 일을 하고 이렇게 컨트롤 할까.

Fork() System call의 return value에 주목해야 한다.
부모 프로세스한테는 return value로 자기가 만든 자식 프로세스의 pid 값이 리턴이 되고, 자식 프로세스한테는 0이 리턴됨

 

C코드로 예시를 보자

fork()를 호출한 직후 부모 프로세스는 어떤 명령을 수행할 차례일까.
fork()의 리턴 value를 받아서 pid 변수에 넣어줄 차례다. 즉, PC는 fork()의 return 값을 받아 pid 변수에 넣어주는 Instruction을 가리키고 있음. 그런데 자식 프로세스의 PC역시 똑같은 곳을 가리키고 있다.
그래서 여기서 같은 value를 return하면 두 프로세스를 영원히 구분할 수 없게 된다.

그런데 자식 프로세스에겐 다른 일을 시키는 것이 우리의 목표임.

return 값을 다르게 줘서 구분될 수 있도록 한다.

부모 프로세스에겐 자식 프로세스의 pid를 리턴, 자식 프로세스에겐 0을 리턴.

그러면 모든 게 같지만 pid 변수에 들어있는 값이 다른 프로세스가 만들어진다.

 

그리고 execlp를 호출하는 순간 ls 프로그램에 해당하는 내용으로 자식 프로세스의 Address Space가 채워지게 된다.

 

---

Single and Multithreaded Processes

멀티 스레드 프로세스에서 하나의 프로그램 내의 각각의 스레드들은 프로세스가 아니기 때문에 코드는 개별적으로 가질 수 없음. 그리고 어느 부분을 수행하고 있든 전역 변수는 공유가 되어야 한다.
=> 코드와 전역변수, 오픈된 파일은 공유를 해야 함.

그럼 스레드들이 개별적으로 가지고 있어야 하는 값은 어떤 게 있을까.
각 스레드 마다 다른 function을 수행하기 때문에 스택영역에 저장되는 function call과 관련된 정보들 return address, parameter, local variable과 같은 데이터들은 다르게 가질 수 밖에 없음
=> Stack 영역은 각자 가질 수 밖에 없다.
=> 그리고 다른 부분의 코드를 수행하기 때문에 레지스터값은 당연히 다르다.

 

Benefits of Multithreaded Process

1. 하나의 스레드를 사용해서 프로세스가 동작하면, I/O가 발생하거나 끝날 때까지 기다려야 하는 System call이 호출되면  프로세스는 멈춰야만 한다(waiting 상태가 되어야만 함)
=> 이 프로세스를 여러 개의 스레드로 만들고 각 스레드가 다른 일을 하게 한다면, 특정 스레드만 멈추면 됨. 프로세스 전체 입장에서는 진도가 나가고 있다. 그렇게 되면 프로세스의 응답성이 좋아진다.

2. 프로세스를 여러 개 만들면 같은 일을 하는 프로세스라도 각각의 Address space를 가진다. 같은 일을 하는 프로세스니까 내용이 완전히 같은 Address space를 갖게 된다. 동일한 내용의 text, data 영역이 여러 개 만들어져서 메모리에 올라가므로 자원이 낭비됨.
=> 스레드를 사용하면 자원을 공유하여 효율적으로 사용할 수 있다.

3. 프로세스를 여러 개 만드는 것은 스레드를 여러 개 만드는 것보다 오버헤드가 크다.
같은 내용의 프로세스를 여러 개 만들면 만들 때마다 Addresss space 전체를 복사해야 함. 스레드를 여러 개 만들면 Stack이랑 Register 값만 복사하면 됨

4. 확장성의 차이.
멀티 코어일 때 프로세스가 하나라면, 하나의 프로세스는 절대 여러 코어에서 수행될 수가 없음. 그런데 그 프로세스가 여러 개의 스레드로 구성되어 있으면, 하나의 프로세스라도 여러 코어에서 돌아갈 수 있음.
=> 그러면 진도가 훨씬 빨리 나가게 된다

 

*모든 내용은 한양대학교 강수용 교수님의 강의 내용을 참고하여 작성되었습니다.