Process

kocw 강의 : 이화여자대학교 반효경 교수님의 운영 체제 강의,4강 Process 1

 

Process is a "program in execution"

 

프로세스의 문맥(context)

• 특정 시점을 놓고 봤을 때, 프로세스가 무엇을 어떻게, 어디까지 실행을 했는지
• process라는건 실행되면 process만의 독자적인 주소 공간 생성 (code, data, stack 로 구성됨)
• process가 cpu 를 잡게되면, pc (program counter)가 code 의 어느 부분을 가리키게 되고,
• 매순간, code안의 instruction 을 읽어서, cpu 안으로 불러드려서, register 에 넣고 alu 에서 연산을 해서 register 에 저장하거나 memory 에 저장
• 위 단계를 거치다가, 프로세스가 어디까지 진행이 되어 있는가를 알려면, 문맥이 필요
  • code 에서 함수를 실행했으면 stack 에 있을꺼임
  • 변수값이 변화했으면 data에 있을꺼임
  • code에서 어느 instruction 까지 실행을 했는가
• 쨋든 process의 context를 알기 위해서는 아래의 세 가지 정보가 필요하다.
  • cpu 수행 상태를 나타내는 hardware context
    • 현재 시점에 process 가 instruction을 어디까지 실행했는가
    • register 에 어떤 값을 넣고 있는가
    • program counter 가 어떤 값을 가리키고 있는가
  • memory와 관련된 proram의 주소 공간
    • code, data, stack 에 어떤 데이터가 들어있는가
  • process 관련 kernel 자료 구조
    • 운영 체제가 역할 중에 하나가 컴퓨터 안에 도는 process를 관리
    • process 생길 때마다 os 는 process를 관리하기 위해서 자신의 data 영역에 pcb라는걸 둔다. (process control block) 얘는 kernel 영역에 저장되는 얘인데, process의 상태나, context 들을 저장해둔다. context switch 에 중요한 역할을 함
    • 각 process 가 자기 자신의 코드를 실행할 때는 함수 호출이 이뤄지면 stack 에 호출한다. process가 실행하다가 자신이 할 수 없는 일을 os 에게 요청하게 되면 (system call) program counter 가 커널 주소 공간을 가리키게 된다. 이 때, kernel 주소 공간은 다양한 process들이 공유하기 때문에 kernel 주소 공간의 kernel stack 는 process 별로 별도의 stack 을 가지게 된다.

 

프로세스의 상태 (state)

cpu 가 하나만 있는 상황으로 간주

• running
  • cpu 를 잡고 instruction을 수행하고 있는 상태
• ready
  • cpu 를 기다리는 상태, (모든 조건이 만족, disk 에 있는 데이터가 memory에 올라와 있지 않으면 ready가 아님)
  • 이 상태에 있는 process들이 cpu 를 잡았다 말았다 하는거임
• blocked (wait, sleep)
  • cpu를 줘도 instruction을 수행할 수 없는 상태 (왜 줘도 먹지를 않니.. 상태)
  • process 자신이 요청한 event (ex. I/O) 가 즉시 만족되지 않아 이를 기다리는 상태
• suspended (stopped)
  • 위 세 가지의 state는 일단 열심히 일을 하는 중에 발생한 state. 하지만 해당 state는 수행이 그냥 정지된거임 
  • 외부적인 이유로 process의 수행이 정지된 상태 (외부 : mid-term scheduler)
  • process는 통째로 disk에 swap out 된다
    • 메모리에 너무 많은 process가 올라와 있어서 mid-term scheduler 가 swap out 한 경우
  • 외부에서 resume 해줘야 resume

 

Process Control Block (PCB)

os가 각 process를 관리하기 위해 process 당 유지하는 정보

다음의 구성 요소를 가짐 (보면 context에 관한 것임을 알 수 있다)

• os 가 관리 상 사용하는 정보
  • process state, process id
  • scheduling information, priority (항상 먼저 온 순서대로 처리하는 것은 아니다)
• cpu 수행 관련 hardware 값
  • process counter (pc), registers
• 메모리 관련
  • code, data, stack 의 위치 정보
• 파일 관련
  • open file descriptors

문맥 교환 (context switch)

• cpu를 한 process에서 다른 process로 넘겨주는 과정
  
  • cpu 를 내어주는 process state 를 그 process의 pcb에 저장.
    • process의 pcb란 kernel 주소 공간의 data에 process 별로 별도의 관리되는 pcb가 있다. 그것을 이야기하는 것
  • cpu 를 새롭게 얻는 process의 상태를 pcb에서 읽어옴. cpu 가 다른 process로 넘어갈 때 os 는 다음을 수행

 

user process가 바뀌어야 그것을 context switch 라고 하는거다. system call이나 context switch 발생할 때 항상 context switch 가 발생하는 것은 아님. 아래의 1,2 번 모두 pcb에 process context 를 저장해야 하지만, 2의 경우가 부담이 훨씬 크다고 한다 (cache memory flush 등이 발생한다고 함)

 

아래는 process scheduling queue 의 모습이다.

 

프로그램이 실행되면 ready queue 로 감. 그러다가 자기 차례가 되면 cpu 로 간다. 그러다가 시간이 되거나, interrupt 가 되거나, i/o requests 가 되거나 하면 다시 ready queue 로 간다. 또한 자식 프로세스를 만들 수도 있음, 그런 경우에도 ready queue 로 간다.

 

scheduler

• short-term scheduler (cpu scheduler)
  • 어떤 process를 다음번에 running 시킬지 결정
  • millisecond 단위
• long-term scheduler (job scheduler)
  • 시작 프로세스 중 어떤 것들을 ready queue 로 보낼 지
    • state 에서 new -> ready 로 가는 것
    • admit 이 필요
    • process 에 memory를 주는 문제
  • degree of multiprocessing 을 제어 -> memory에 올라가는 process의 수
  • time sharing system 에는 보통 long-term scheduler 없음. 그냥 곧바로 ready state가 됨
• medium-term scheduler (swapper)
  • 여유 공간 마련을 위해 process를 통째로 memory에서 disk로 쫓아냄
  • process에게서 memory를 뺏는 문제
  • degree of multiprocessing 을 제어 -> memory에 올라가는 process의 수 

일반적인 os 가 long-term 이 아닌 mid-term 을 쓰는데, 어떤 Process를 memory에 올릴 지를 고민하지 않고, 올라간 process 중 어떤 것을 뺏을 지를 고민하는 것이 효과적이기 때문인 것 같다.