[운영체제] Day03. Process

프로세스와 문맥(Context)

• 문맥 : 프로세스의 진행 정도를 나타낸다.
  1. CPU 수행 상태를 나타내는 하드웨어 문맥 :
     Instruction 진행 정도, register가 어떤 값을 저장하고 있었는가?
  2. 프로세스의 주소 공간 :
     주소 공간(code, data, stack)에 어떤 값이 들어가있는가?
  3. 프로세스 관련 커널 자료 구조 :
     PCB (프로세스 감시, 자원 할당 정도 결정)
     Kernel Stack (유저 스택 말고 커널 주소 공간의 스택도 필요)

프로세스의 상태(State)

1. Running :
   CPU 잡고 Instruction 수행 중
2. Ready :
   CPU 기다리는 중 (메모리에 코드 올라가 있는 등 다른 조건 모두 만족 중
3. Blocked :
   CPU 줘도 Instruction 못함 (Process 자신이 요청한 event가 만족되지 않은 상태)
   스스로 정지 -> 스스로 Ready로 복귀 가능
4. Suspended(Stopped) :
   중기 스케줄러에 의해 프로세스 수행이 정지된 상태 (메모리 뺏김)
   외부에 의해 강제 정지 -> 외부에 의해 재개 필요
5. New : 프로세스 생성 중 / Terminated : 수행 완료

프로세스 상태 주기 생성 후 Ready 상태 -> CPU 획득 시 running -> I/O 필요 시 CPU 반환, Interrupt 발생 후 Blocked로 돌아감 -> I/O 받은 후 Ready로 돌아감 -> CPU 다시 받음 -> ... -> 이후 종료

유의
프로세스가 I/O 등을 위해서 OS에게 주도권을 위임할 때도 OS를 실행한다고 표현하지는 않음.
프로세스의 입장에서는 시스템 콜(System Call)을 통해 OS Kernel의 코드를 실행하는 커널 모드(Kernel Mode)로 작동하는 것이다.
이처럼 프로세스는 User Mode와 System Call을 통한 Kernel Mode를 오가며 실행된다.

Process Control Block (PCB)

• 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보
• 다음의 구성 요소를 가진다.
  1. OS가 관리상 사용하는 정보 : Process State(ID), 스케줄링 정보, 우선순위
  2. CPU 수행 관련 하드웨어 정보
  3. 메모리 관련
  4. 파일 관련

문맥 교환 (Context Switch)
CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
CPU가 다른 프로세스에 넘어갈 때 ...
1. CPU를 내어주는 프로세스 상태를 그 프로세스의 PCB에 저장. (커널 내 프로세스 주소 영역의 PCB)
2. CPU를 얻는 프로세스 상태를 그 프로세스 PCB에 저장된 상태로 불러와 갱신
Interrupt/System Call 발생해도 문맥 교환이 일어나지 않을 수도 있다!

• timer interrupt의 경우 다른 프로세스로 CPU 넘기려는 목적 -> 문맥 교환 발생
• I/O 요청 -> 시간 오래 걸림 -> 문맥 교환 발생
• 하지만 다른 interrupt나 System Call은 짧은 시간 내에 원래 프로세스로 바로 돌아가므로 문맥 교환 안해도 됨.
• 물론 해당 경우에도 PCB에 Context 일부를 저장해야 하지만, 프로세스가 바뀌는 1, 2번의 Case가 부담이 더 크다.

프로세스 스케줄링 큐의 모습

CPU 획득 -> I/O request 하며 CPU 반납 -> I/O Queue에서 줄 서기 -> 획득 -> 다시 CPU 얻으려고 ready Queue 가서 줄 서기 -> CPU 획득 -> ...

스케줄러 (Scheduler)

Long-term Scheduler (장기 스케줄러, job scheduler)

• 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정
• 프로세스 생성 시 new -> ready로 State 바뀌면서 메모리 할당
• degree of multiprogramming 제어 (메모리에 몇 개의 프로그램이 올라갈지)
• 너무 프로그램을 적게 올려도, 많이 올려도 성능 저하 발생
• time sharing system에는 보통 장기 스케줄러 없음(무조건 ready)

Medium-term Scheduler (중기 스케줄러, Swapper)

• 처음 프로세스 생성 시 메모리에 올라간다.
• 메모리에 너무 많이 프로레스 올라갈 시 여유공간 마련을 위해 프로세스를 메모리에서 쫓아내는 역할

  (사용자) 프로세스 상태도

  moniter mode 실행 시 OS가 실행된다 X -> 사용자 프로세스의 커널 내 코드가 실행된다.

Short-term Scheduler (단기 스케줄러)

• 어떤 프로세스를 다음 번에 Running 할지 결정
• 프로세스를 CPU를 주는 문제
• 충분히 빨라야 함

Thread (Lightweight Process)

CPU 수행 단위.

• 구성(공유 X) : program counter, register set, stack space
• 공유 부분(task) : code section, data section, OS resources
• 하나의 프로세스를 여러 개 띄워두고 싶을 때 메모리에 여러 번 기록할 필요 없음 -> 메모리에는 하나만 띄워두고 PCB에서 Code 어디까지 읽었는지를 기록하는 Program Counter를 여러 개 두면 된다.
• 여러 쓰레드는 메모리 주소 공간, 프로세스 상태, 자원을 공유한다.
• Program Counter, Register, Stack만 별도로 저장

전통적 Process (하나의 쓰레드) : Heavy weight Process

Thread 사용의 장점

• 응답성
  하나의 Thread가 Blocked 여도 다른 Thread가 Running 가능 (사용자가 느끼기에 빠른 응답성)
• 자원 공유
  여러 쓰레드 간 자원 공유 -> 효율적 사용
• 경제성
  프로세스 하나 만드는 것보다 쓰레드 하나 만드는게 빠름
  프로세스 간에 switch 보다 쓰레드 간 switch가 빠름
• 다중 CPU 환경에서의 이점
  각각의 Thread가 다른 CPU에서 병렬 작업 가능

Thread 사용 방법

1. Kernel
   프로세스 안 Thread가 여러 개라는 사실을 Kernel이 알고 있음
   Kernel이 관리함.
2. User Threads
   Library로 지원
   프로세스 안 Thread가 여러 개라는 사실을 Kernel이 모름
   프로세스 본인이 관리.