[OS] Process

🤔 프로세스의 개념

“Process is a program in execution”

프로세스의 문맥 (context) : 프로세스의 현재 상태를 알아야 할때 확인해야 하는 정보들

1. CPU 수행 상태를 나타내는 하드웨어 문맥

• Program Counter (PC가 어딜 가리키고 있는가?)
• 각종 Register (어떤 값을 현재 가지고 있었는가?)

2. 프로세스의 주소 공간

• code, data, stack (에 어떤 내용이 들어가 있는가?)

3. 프로세스 관련 커널 자료 구조

• PCB(Process Control Block) (운영체제는 프로세스를 관리하기 위해 자신의 DATA 영역에 자료구조를 둔다 - PCB )
• Kernel stack (system call을 하게 될때, 커널의 함수 호출이 이루어지면 stack에 관련된 정보들이 쌓일텐데 그게 커널 스택이다. 이 커널 스택은 어떤 프로세스든 간에 운영체제에게 요청할때 커널의 코드를 실행하게 된다. 때문에 커널 스택은 프로세스마다 별도로 둔다.)

[ 자세한 설명 ]

프로세스는 시작이 되면 독자적인 주소 공간이 생성된다. (code, data, stack) 매 순간 인스트럭션을 하나씩 읽어서 CPU안으로 불러들이고, 레지스터에 어떤 값을 넣고, 산술 논리 연산 장치에서 연산을 하고, 그 결과를 레지스터에 저장하거나 또는 바깥 메모리에 저장하거나 하는 방식으로 진행한다.

어느 시점에 이 프로세스는 어디까지 와있는가를 규명하는데 필요한 것이 프로세스 문맥이다. PC가 어딜 가리키고 있는가 (CODE의 어느 부분까지 실행했는가), 이 프로세스 메모리에 어떤 내용을 담고 있는가(STACK에 쌓인 함수 확인), 지금 이 변수의 값은 얼마이며(DATA), 레지스터에 어떤 값을 넣었고 어떤 인스트럭션을 실행했는가를 모두 알아야지만 이 프로세스의 현재 상태를 나타낼 수 있다.

이러한 모든 요소들을 프로세스의 문맥이라고 부른다.

✨ 프로세스의 상태

컴퓨터 안에 cpu는 하나이다. cpu를 잡고있는 프로세스는 매 순간 하나이다.
프로세스는 상태(state)가 변경되며 수행된다. 크게 세 가지로 구분

1. Running : CPU를 잡고 instruction을 수행중인 상태
2. Ready : CPU를 기다리는 상태(메모리 등 다른 조건을 모두 만족하고)
3. Blocked (wait, sleep) : CPU를 주어도 당장 instruction을 수행할 수 없는 상태
   : Process 자신이 요청한 event(I/O 등)가 즉시 만족되지 않아 이를 기다리는 상태
   : EX) 디스크에서 file을 읽어와야 하는 경우 (오래 걸리는 작업)

추가로 구분

4. New : 프로세스가 생성중인 상태
5. Terminated : 수행(execution)이 끝난 상태

[ 자세한 설명 ]

위의 그림의 리소스 큐, 디스크 아이오 큐, 키보드 아이오 큐, 레디 큐는 가상의 모습이다. 또한 큐가 먼저온 순서대로 처리하는 것도 아니다. 사실 정확한 cpu 스케줄링은 우선순위가 높은애에게 넘겨준다.

프로세스가 레디 큐에서 기다리고있다가 cpu 제어권을 얻음
→ time이 끝나면 다시 레디 큐 맨뒤에서 줄을 선다.
→ 디스크에서 입출력을 할려면 해당 큐에 들어가서 줄선다. (이때 프로세스 상태는 blocked)
→ 작업이 끝나면 디스크 컨트롤러가 cpu에게 인터럽트를 건다.
→ cpu는 하던 작업을 잠시 멈추고 cpu제어권이 운영체제 커널에게 넘어간다
→ 운영체제 커널은 프로세스의 i/o작업이 끝났으므로 해당하는 데이터를 프로세스의 메모리 영역에 넘겨준다. 또한 프로세스의 상태를 blcoked에서 ready로 바꿔서 cpu의 제어권을 얻을 수 있도록 줄을 세워준다.

공유 데이터라는 것이 있는데 여러 프로세스가 동시에 접근하면 일관성이 깨지는 문제가 생긴다. 그래서 어떤 프로세스가 공유데이터에 접근하고 있으면 다른 것이 접근하지 못하도록 해야하는 시스템이 필요한데, 그렇기 때문에 리소스 큐에 프로세스는 blocked상태로 기다린다.

즉, 오래 기다리는 작업이 있으면 프로세스는 blocked가 된다는 것.

실제로는 운영체제 커널의 data 영역에 자료구조로 큐를 만들어놓고 프로세스의 상태를 바꿔가면서 ready 상태에 있는 프로세스에게 cpu를 주고 blocked이면 cpu를 안주고 .. 이런 식으로 운영하는 것이다.

✨ Process Control Block (PCB)

PCB

• 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보
• 다음의 구성 요소를 가진다 (구조체로 유지)
  

1. OS가 관리상 사용하는 정보

• Process state, Process ID
• scheduling information, priority

2. CPU 수행 관련 하드웨어 값

• Program counter, registers

3. 메모리 관련

• Code, data, stack의 위치 정보

4. 파일 관련

• Open file descriptors...

✨ 문맥 교환(Context Switching)

짧은 시간 간격으로 CPU를 얻었다가 뺏는 작업을 반복하게 된다.
뺏기고 나서 다시 실행 될때 처음부터 실행되는것이 아니라 뺏기기 전 그 문맥을 기억했다가 다음에 그 시점부터 실행하게 된다.

• CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
• CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행
• CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장 (커널의 메모리에 있는 레지스터의 값들을 PCB에 SAVE를 해놓는다.)
• CPU를 새롭게 얻는 프로세스의 문맥을 PCB에서 읽어옴

System Call이나 Inturrupt 발생시 반드시 Context Switch가 일어나는 것은 아니다.

• system call : 프로세스가 본인이 필요해서 운영체제에게 인터럽트 요청하는 것.
• inturrupt (하드웨어) : 컨트롤러같은 장치가 cpu에게 정보를 전달할 목적으로 인터럽트 거는 것.

이것이 발생 시 사용자 프로그램으로 부터 cpu제어권이 운영체제로 넘어가게 된다. 이것이 context switch는 아니다. context switch는 사용자 프로세스로부터 다음 사용자 프로세스로 넘어가는 과정을 말하는 것이다.

(1)은 그저 user mode → kernel mode → user mode인 것이고
(2)는 다른 프로세스에게 넘겨야 하기 때문에 문맥교환이 일어난다.

(1)의 경우에도 문맥 교환이 일어나지 않았지만 사용자 코드를 실행하다가 → 커널의 코드를 실행하고 → 다시 사용자 코드로 실행했기 때문에 cpu 수행 정보 등 약간의 context의 일부를 PCB에 save 한 후 복원해야 하지만, 문맥 교환을 하는 (2)의 경우 그 부담이 훨씬 크다.

막강한 오버헤드가 든다. (ex. cache memory flush : cpu와 메인 메모리 사이에 있는 빠른 메모리 장치. 보통 프로세스 a→b가 바뀌면 캐시 내용을 다 지워야 한다. 하지만 (1)의 상황에서는 캐시 메모리 플러시가 필요 없다.)

✨ 프로세스를 스케줄링하기 위한 큐

• Job queue : 현재 시스템 내에 있는 모든 프로세스의 집합
• Ready queue : 현재 메모리 내에 있으며 CPU를 잡아서 실행되기를 기다리는 프로세스의 집합
• Device queue : I/O 처리를 기다리는 프로세스의 집합

프로세스들은 각 큐들을 오가며 수행한다.

Ready Queue와 다양한 Device Queue

운영체제가 이들을 관리함.

✨ 스케줄러(Scheduler)

1. Long-term scheduler (장기 스케줄러 or job 스케줄러)

→ 보통 우리가 사용하는 시스템 장기 스케줄러가 없다. 어떤 프로그램이 시작 되면 곧바로 메모리로 올라간다. (100개를 올려놓으면 레디에 100개가 올라간다.)
→ 그렇다면 이 장기 스케줄러를 어떻게 조정하냐 ?
→ 미디엄 텀 스케줄러가 조정한다!

• 프로세스가 시작 될 때 new→ready로 넘어가는 과정에서 메모리에 올라가는 것을 admitted. 메모리에 올라가는 것을 허락하게 되면 ready상태가 되어서 cpu를 얻을 수 있는 상태가 되는 것. 이걸 결정하는 것이 롱텀 스케줄러다.

• 시작 프로세스 중 어떤것들을 ready queue에 보낼지 설정

• 프로세스에 memory(및 각종 자원)을 주는 문제

• degree of multi-programming(메모리에 여러 프로그램이 동시에 올라가는 것)을 제어
  → 메모리에 올라오는 프로그램 수를 조절해야 하는 필요가 있다.
  (메모리에 너무 많은 프로그램이 동시에 올라가면 컴퓨터 성능이 안좋아지고,
  너무 적게 올라가도 성능이 안좋아진다. → cpu가 놀기 때문에)
  그래서 메모리에 몇개의 프로그램이 올릴건지 결정하는 것이다.

• time sharing system에는 보통 장기 스케줄러가 없음(무조건 ready)

2. Short-term scheduler (단기 스케줄러 or CPU 스케줄러)

• 어떤 프로세스를 다음번에 running 시킬 지 결정 (어떤 프로세스에게 cpu를 줄지 결정하는 것)
• 프로세스에 cpu를 주는 문제
• 충분히 빨라야 함(millisecond 단위)

3. Medium-term scheduler (중기 스케줄러 or swapper 스와퍼)

→ 일단 메모리에 다 올려 놓고 너무 많은 프로그램이 올라가져 있으면 몇개를 쫓아내는 방식.

• 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
  (메모리에 너무 많은게 동시에 올라가져 있으면 일부 프로그램을 골라서 메모리에서 쫓아낸다.)
• 프로세스에게서 memory를 뺏는 문제
• degree of multiprogramming 을 제어
• 그래서 현대의 운영체제에서는 프로세스의 상태 3가지(러닝, 레디, 블락)에 중기 스케줄러 때문에 상태가 추가된 것이 있다. 그 상태가 바로 Suspended 상태이다.

✨ 프로세스의 상태

1. Running : CPU를 잡고 instruction을 수행중인 상태
2. Ready : CPU를 기다리는 상태(메모리 등 다른 조건을 모두 만족하고)
3. Blocked (wait, sleep) : CPU를 주어도 당장 instruction을 수행할 수 없는 상태
   : Process 자신이 요청한 event(I/O 등)가 즉시 만족되지 않아 이를 기다리는 상태
   : EX) 디스크에서 file을 읽어와야 하는 경우 (오래 걸리는 작업)

4. Suspended (stopped)
   : 외부적인 이유로 프로세스의 수행이 정지된 상태
   : 프로세스는 통째로 메모리에서 쫓겨나서 디스크에 swap out 된다.
   : EX) 사용자가 프로그램을 일시 정지 시킨 경우(break key) → 사람이 정지시킴 그래서 사람이 재개시켜야지만 다시 액티브할수 있다. 시스템이 여러 이유로 프로세스를 잠시 중단시킴 (메모리에 너무 많은 프로세스가 올라와 있을 때 → 중기 스케줄러)