[반효경 교수님 - 운영체제] Process

프로세스의 개념

 

"Process is a program in execution" => 프로세스는 실행중인 프로그램을 의미.

 

프로세스의 문맥(context)

 

프로그램이 실행되다 언젠간 종료가 될텐데 문맥이라는 것은 중간 어떤 시점에서 잘라놓고 봤을 때 이 프로그램이 무엇을 어떻게 실행했는지, 현재 시점이 어떤 상태에 있는지를 정확하게 나타내기 위해 사용되는 개념.

 

-> 프로세스가 시작되면 독자적인 주소 공간을 생성한다. 이 프로세스가 CPU를 잡게 되면 PC라는 레지스터가 프로세스 코드의 어느 부분을 가리키고 있고, 매 순간 instruction을 읽어 CPU안의 레지스터에 값을 넣고 ALU(연산 장치)에서 연산 후 그 결과를 레지스터 또는 메모리에 저장한다. 이 과정을 계속해서 진행하다가 이 프로세스가 어디까지 와있는지 규명하기 위해 필요한 요소가 프로세스 문맥이다.

• CPU 수행 상태를 나타내는 하드웨어 문맥
  - program counter
  - 각종 register
  주로 레지스터가 현재 어떤 값을 가지고 있는가로 나타냄.
• 프로세스 주소 공간(메모리와 관련)
  - code, data, stack에 어떤 내용이 들어있는지.
• 프로세스 관련 커널 자료구조
  - PCB
  - kernel stack
  프로세스 별로 커널을 어떤 프로세스가 호출했는지에 따라서 stack을 별도로 두고 있음. 이렇게 해야 정보가 꼬이는 등의 문제를 막을 수 있음.

=> 프로세스가 혼자 실행이 된다면 위의 설명이 필요하지 않음. 하지만 컴퓨터 시스템에선 time sharing, multitasking, 즉, 프로세스들이 번갈아가면서 실행되기 때문에 문맥을 알아야함.

 

 

프로세스의 상태

커널 주소 공간의 data부분에 queue들이 들어있고 ready상태인 프로세스에게 CPU를 주는 식으로 운영됨.

 

CPU는 굉장히 빠르고 여럿이 공유하는 자원임.

 

디스크에서 읽어와야할 경우 프로세스의 상태는 blocked로 바뀌면서 disk I/O queue에서 대기 요청한 I/O 작업이 끝나면 disk controller가 CPU한테 interrupt를 걸고 현재 프로세스를 수행 중인 CPU는 interrupt로 인해 하던 작업을 멈추고 CPU제어권이 커널에게 넘어감. 그러면 운영체제는 프로세스의 상태를 바꾸어줌.

 

프로세스는 상태(state)가 변경되며 수행됨.

 

PCB

-> 운영체제가 각 프로세스를 관리하기 위해 프로세스 당 유지하는 정보.

아래와 같은 구성 요소를 가짐 (구조체로 유지)

1. OS가 관리상 사용하는 정보
   - process state, process ID
   - scheduling information, priority
   (프로세스에게 CPU를 주기 위한 우선 순위나 스케줄링 정보가 있음)
2. CPU 수행관련 하드웨어 값 (프로세스의 문맥을 표시하기 위한 정보)
   - program counter, registers
   
   
3. 메모리 관련 문맥
   - code, data, stack의 위치 정보
   
   
4. 파일 관련
   - open file descriptors...

문맥 교환 (context switch)

-> 프로세스들은 짧은 시간 간격으로 CPU를 얻었다가 뺏겼다가를 반복하는데, 이때 뺏겼다가 다시 얻으면 처음이 아닌 뺏기던 시점의 문맥을 기억해놨다가 그 시점부터 실행할 수 있기 위한 매커니즘이 필요.

• CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
• 문맥 교환 시 필요한 과정
  CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장
  -> CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴.

문맥 교환 시 헷갈릴 수 있는 것들

 

시스템콜이나 interrupt 발생 시 반드시 context switch가 일어나는 것은 아님.

* 시스템콜: 프로세스가 본인이 필요해서 운영체제한테 요청할 때
* interrupt: 컨트롤러같은 장치가 CPU한테 정보를 전달할 목적으로 거는 것.

system call이나 interrupt가 발생하면 CPU 제어권이 운영체제 커널한테 넘어감. 이땐 CPU가 사용자 프로세스로부터 운영체제한테 넘어간 것이므로 context switch가 아님.

 

위 그림에서 (1)의 경우에도 CPU 수행 정보 등 context의 일부를 PCB에 save해야함. 하지만 문맥 교환을 하는 (2)의 경우 그 부담이 훨씬 큼.

* timer interrupt: CPU를 다른 프로세스에게 넘기기 위한 의도를 가진 interrupt

* I/O요청 system call: I/O는 오래걸리기때문에 다른 Ready상태의 프로세스에게 넘겨줌.

 

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

• Job queue
  현재 시스템 내에 있는 모든 프로세스의 집합
  -> Ready, Device queue 모두 포함
• Ready queue
  현재 메모리 내에 있으면서 CPU를 잡아서 실행되기를 기다리는 프로세스의 집합
• Device queue
  I/O device의 처리를 기다리는 프로세스의 집합

스케줄러 (Scheduler)

• Long-term scheduler (장기 스케줄러 or job scheduler)
  - 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정
  - 프로세스에 memory(및 각종 자원)을 주는 문제
  - degree of Multiprogramming을 제어 -> 메모리에 올라가는 프로그램 수(너무 많거나 적으면 안됨)
  - time sharing system에는 보통 장기 스케줄러가 없음 (무조건 바로 ready상태)
• Short-term scheduler (단기 스케줄러 or CPU scheduler)
  - 어떤 프로세스를 다음 번에 running시킬 지 결정
  - 프로세스에 CPU를 주는 문제
  - 충분히 빨라야 함(millisecond 단위) -> 짧은 시간 단위로 이루어지기 때문에 Short-term
• Medium-term scheduler (중기 스케줄러 or Swapper)
  - 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
  - 프로세스에게서 memory를 뺏는 문제
  - degree of Multiprogramming을 제어
  - 일단 메모리에 다 올려놓고 너무 많은 경우에 일부를 쫓아냄.

프로세스의 상태

• Running
  CPU를 잡고 instruction을 수행중인 상태
• Ready
  CPU를 기다리는 상태(메모리 등 다른 조건을 모두 만족하고)
  -> CPU만 얻으면 instruction을 수행할 수 있는 상태
• Blocked (wait, sleep)
  CPU를 주어도 당장 instruction을 수행할 수 없는 상태
  Process 자신이 요청한 event(예: I/O)가 즉시 만족되지 않아 이를 기다리는 상태
  (예) 디스크에서 file을 읽어와야 하는 경우
• Suspended (stopped)
  외부적인 이유(중기 스케줄러)로 프로세스의 수행이 정지된 상태
  프로세스는 통째로 디스크에 swap out됨.
  (예) 사용자가 프로그램을 일시정지시킨 경우
  시스템이 여러 이유로 프로세스를 잠시 중단시킴(메모리에 너무 많은 프로세스가 올라와있을 때)
  
  
• New
  프로세스가 생성 중인 상태
• Terminated
  수행(execution)이 끝난 상태

*Blocked: 자신이 요청한 event가 만족되면 Ready(자신이 요청한 일을 오래 기다림)
*Suspended: 외부에서 resume해 주어야 Active(외부에서 정지시켜놓은 상태)

 

프로세스의 상태도

- 프로세스가 CPU를 가지고 있으면서 본인의 코드를 실행 중인 상태가 user mode의 running

- inactive는 외부적인 이유로 프로세스가 정지된 상태이므로 외부에서 재개해줘야만 active상태가 됨.

- Suspended는 메모리를 완전히 잃어버려 CPU관점에서는 아무 일을 할 수 없지만, I/O같은 작업이 진행중이라면 진행해서 Suspended Ready  상태로 갈 순 있음.

 

*주의*

프로세스 본인이 일을 할 수 없어 운영체제한테 대신 요청하는 시스템콜을 하게 되면 운영체제 코드가 실행한다. 이때 프로세스가 CPU를 잃고 운영체제가 CPU를 얻었다고 운영체제 커널이 running하고 있다고 표현하지 않는다. 

이때에도 그 사용자 프로세스가 커널모드에서 running하고 있다고 표현한다.

 

 

Thread

"A thread (or lightweight process) is a basic unit of CPU utilization" 

=> thread는 프로세스 내부에 CPU 수행 단위가 여러 개 있는 경우에 그것을 thread라고 부름.

 

Thread의 구성

• Program Counter(PC)
• register set
• stack space

Thread가 동료 thread와 공유하는 부분( = task)

• code section
• data section
• os resources

=> 전통적인 개념의 heavyweight process는 하나의 thread를 가지고 있는 task로 볼 수 있다.

 

동일한 일을 하는 프로세스가 여러 개 있을 때, 이것을 별도의 프로세스로 각각 만들면 메모리 낭비가 큼. 주소 공간을 하나만 쓰고 각 프로세스마다 다른 부분의 코드를 실행할 수 있게 해주면 됨.

즉, 프로세스는 하나만 띄워놓고 현재 CPU가 코드의 어느 부분을 실행하고 있는가를 나타내는 PC만 여러개를 둠.

-> 프로세스 하나에 CPU 수행단위만 여러 개 두고있는 것을 thread라고 함.

 

CPU 수행을 위해서는, 즉 instruction을 수행하려면 현재 코드의 어느 부분을 수행하고 있는 지를 가리키는 PC가 있어야하고, 그 CPU에서 실행되면서 메모리에 register 값들을 세팅해놓고 실행할 것이므로, 각 thread마다 현재 레지스터에 어떤 값을 넣고 PC가 코드 어느 부분을 가리키고 실행하고 있었는가를 별도로 유지.

 

Thread 하나가 코드 어느 부분을 실행하다가 함수 호출을 하면 관련 정보를 stack에 쌓아야하는데 CPU 수행단위가 여러 개 있게 되면 stack도 별도로 두어야 함.

 

=> Thread는 프로세스 하나에서 공유할 수 있는 것을 최대한 공유

(메모리 주소공간, process는 하나이므로 process state도 공유, process가 사용하는 자원들도 thread끼린 공유).

다만 별도로 가지고 있는 것은 CPU 수행과 관련된 정보( PC, register, stack)

 

Thread 장점

• Responsiveness (응답성)
  사용자 입장에서 답답하지 않음.
  (예) 웹 브라우저를 이용할 때 네트워킹을 통해 웹 페이지를 읽어와야함(I/O작업). 그 동안 웹 브라우저는 blocked 상태인데 이때 여러 개의 thread가 있다면 하나의 thread가 그림 같은 것을 불러오는 동안 이 프로세스를 block 시키지 않고 다른 thread가 텍스트 같은 것들을 미리 보여준다면 덜 답답할 것이다.
  
  
• Resources sharing (자원공유)
  똑같은 일을 하는 프로그램 여러 개를 별도의 프로세스로 사용하면 자원 낭비
  
  
• Economy (경제성)
  프로세스 하나 만드는 것은 오버헤드가 상당히 큼. 하지만 프로세스 안에 thread를 추가하는 것은 오버헤드가 크지 않음.
  context switch가 일어날 때 프로세스에서 프로세스로 넘어가는 것은 오버헤드가 큼. 하지만 thread에서 thread끼리는 간단함.
  
  
• Utilization of MP(Multi Processor) Architectures
  CPU 여러 개인 경우에 해당
  thread를 병렬적으로 사용 가능.

Thread 구현

• Kernel Threads
  thread가 여러 개 있다는 사실을 운영체제 커널이 알고 있음.
  thread A에서 thread B로 가는 것도 커널의 지원을 받아 커널이 관리함.
• User Threads
  라이브러리 형태로 구현
  운영체제가 thread 여러 개라는 사실을 모름.
  따라서 유저 프로그램이 스스로 여러 개의 thread를 관리.
• real-time threads