[OS] Process

kmjoo·2022년 1월 7일
운영체제
0

운영체제 | KOCW 이화여대(반효경)

목록 보기
5/10
post-thumbnail
post-custom-banner

Process = program in execution (실행중인 프로그램)

  • 프로세스는 실행이 시작되면 해당 프로세스만의 독자적인 주소공간을 생성함
    • pc가 해당 프로세스 주소공간의 code 영역의 한 부분을 가리키고 있고, 해당 주소의 instruction을 읽어와서 CPU가 연산함

프로세스의 문맥(context)

Context의 개념

: 프로그램이 태어나서 → 실행 → 종료되기까지의 시간 중에 중간 어느 시점을 잘라놓고 보았을 때,이 프로그램이 무엇을 어떻게 실행했는지, 현재 시점이 어떤 상태에 있는지를 나타내기 위해 사용되는 개념
: 특정 시점을 놓고 보았을 때 이 프로세스가 어디까지 실행되었는가

Context가 담는 내용

  • PC가 어디를 가리키고 있는가
  • code의 어느 부분까지 실행했는가
  • 메모리에 어떤 내용을 담고 있는가
    • data 영역) 현재 변수의 값은 얼마인가
    • stack 영역) 함수를 호출했다면 관련 내용이 stack에 쌓여있을 것
    • register에 어떤 값을 넣어놓고, 어떤 instruction까지 실행했는가

Context의 분류

  • 하드웨어 문맥 : CPU 수행 상태를 나타냄
    • 프로세스는 CPU를 잡고 매순간 instruction을 실행함
    • 현재 시점에 이 프로세스가 instruction을 어디까지 실행했는가?
      • register에 어떤 값을 넣었는가
      • program counter가 어떤 값을 가리키고 있었는가 등
  • 프로세스의 주소 공간 (메모리 관련)
    • 현 시점에 code, data, stack에 어떤 내용이 들어있는가
  • 프로세스 관련 커널 자료 구조
    • 운영체제가 이 프로세스를 어떻게 평가하고 있느냐도 알아야 한다.
    • 운영체제의 역할 중 하나가 현재 컴퓨터 안에서 돌아가는 프로세스들을 관리하는 것임
    • 이를 위해서 OS는 자신의 data영역에 PCB(Process Control Block)라는 자료구조를 두고 있음
      • 프로세스가 하나씩 실행될 때마다 PCB를 하나씩 두면서 이 프로세스에 CPU/메모리를 얼마나 주어야 할지, 나쁜 짓을 하고 있지는 않은지 등을 관리함
    • Kernel stack
      • 각 프로세스가 자기 자신의 코드를 실행 중일 때는 자신의 stack에 호출된 함수를 저장/return한다
      • 그런데 실행 중 system call을 하게 되면, PC가 kernel의 code 영역을 가리키게 되면서 커널의 함수가 호출됨
      • 이때 호출된 함수에 대한 내용이 stack에 쌓여야 함
      • 그런데 커널은 여러 프로세스가 공유하는 코드임. 즉, 어떤 프로세스든 OS에 요청을 할 때 커널의 코드를 실행하게 됨. 따라서 커널이 누구의 부탁을 받고 실행되고 있는지가 매번 다름
        • 따라서 stack에 정보를 쌓을 때는 커널을 어떤 프로세스가 호출했는지에 따라 프로세스별로 stack을 별도로 두고 있음

Context의 필요성

  • 현재의 OS는 time sharing, multi-tasking 등으로 여러 프로세스들이 번갈아서 실행됨
  • 따라서 한 프로세스가 CPU 제어권을 얻고 실행하다가, 다른 프로세스로 CPU가 넘어가는 등의 행동이 반복됨
  • 이때 프로세스의 진행상황, 즉 context를 백업해놓지 않으면, 다음번 CPU를 잡았을 때 어디서부터 실행해야 하는지 알 수 없게 됨

프로세스의 상태 (Process State)

  • 프로세스는 상태가 변경되며 수행됨

Running

  • CPU를 잡고 instruction을 수행중인 상태
  • CPU가 하나인 컴퓨터라면 매 순간 Running 상태의 프로세스는 1개일 것

Ready

  • CPU를 기다리는 상태 (메모리 등 다른 조건을 모두 만족한 채로)

Blocked (wait, sleep)

  • CPU를 주어도 당장 instruction을 수행할 수 없는 상태
  • process 자신이 요청한 event(I/O 등)가 즉시 만족되지 않아 이를 기다리는 상태

Suspended (stopped)

  • 외부적인 이유로 프로세스의 수행이 정지된 상태
    • ex) 사용자가 프로그램을 일시 정지시킨 경우 (break key), 시스템이 여러가지 이유로 프로세스를 잠시 중단시키는 경우 (메모리에 너무 많은 프로세스가 올라와 있을 때)
  • 프로세스는 통째로 디스크에 swap out됨
    • 중기 스케줄러 때문에 메모리를 통째로 빼앗긴 상태
  • 외부에서 resume해주어야 active됨

New

  • 프로세스가 생성 중인 상태

Terminated

  • 수행(execution)이 끝난 상태

프로세스 상태도

  • 기본적인 프로세스 상태도

  • 보다 자세한 프로세스 상태도 (suspended 상태 포함)

    • 프로세스가 system call을 해서 kernel의 code가 실행중일 때에도, “해당 프로세스가 kernel 모드에서 러닝하고 있다” 고 말하지, OS가 러닝하고 있다고 말하지 않음
    • Suspended 상태일 때에도 suspended blocked → suspended ready 로의 상태 변경이 가능함

  • 컴퓨터 입장에서 그린 프로세스 상태도

    • OS 커널은 I/O 작업이 끝났다는 전달을 받으면, 해당 프로세스의 상태를 blocked → ready로 변경하는 일도 함

    • 소프트웨어 자원(ex: 공유데이터)에 접근하기 위해 blocked 되기도 함. 반드시 I/O device 등 하드웨어 자원의 사용을 위해서 blocked되는 것은 아님

      • 동시에 여러 개의 프로세스가 같은 데이터에 접근하면 일관성이 깨지는 등의 문제가 발생할 수 있음

      • 따라서 동시에 접근하지 못하도록 막는 경우도 있음

      • 이럴 때 Resource queue에서 대기하게 됨

        • queue는 OS kernel이 자신의 data 영역에 자료구조로 queue를 만들어놓고, 프로세스의 상태를 바꾸어가면서 운영함

PCB

: OS kernel이 각 프로세스마다 프로세스와 관련된 정보(프로세스를 관리하기 위한 정보)를 자신의 Data 영역에 두는데, 이를 PCB라고 함
: 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보

PCB가 가지는 정보 구성

  • (1) OS가 관리상 사용하는 정보
    • 프로세스의 상태 (process state)
    • 프로세스 ID
    • scheduling information, priority
      • CPU를 넘겨주는 우선순위
  • (2) CPU 수행 관련 하드웨어 값 (프로세스의 문맥을 표시하기 위한 값들)
    • program counter
    • registers
  • (3) 메모리 관련
    • code/data/stack의 위치 정보
  • (4) 파일 관련
    • open file descriptors
      • 프로세스가 open하고 있는 file이 어떤 것인가

문맥 교환 (Context Switch)

  • CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
    - 이 과정에서 OS는 다음의 내용을 수행

    1. CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB(kernel 주소공간의 data 영역에 위치)에 저장
      • register, program counter, memory map 등에 저장된 정보 옮기기
    2. CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 찾아서, CPU에 복원

  • System call이나 interrupt 발생 시 반드시 context switch가 일어나는 것은 아님

    • 해당 event 발생 시 CPU가 사용자 프로세스 → OS로 이동하나, 이후 반드시 다른 사용자 프로세스로 CPU 제어권이 넘어가는 것은 아님 (보통은 기존 프로세스로 다시 CPU가 넘어감)
      • 이 경우에도 프로세스의 주소공간에서 실행되다가, kernel의 code를 실행해야 하므로 약간의 context가 save되어야 할 필요가 있음
      • 그러나 context switch에 비해서는 kernel mode로 들어갔다가 나오는 것이 훨씬 overhead가 적음
        • ex) cache memory flush : context switch가 일어날 때는 cache memory를 모두 지워야 하는데, kernel mode → user mode는 이를 지울 필요까지는 없음. cache memory flush는 매우 큰 overhead임
    • 사용자 프로세스 → 다른 사용자 프로세스로 CPU 제어권이 넘어가는 것을 context switch라고 함
    • timer interrupt는 다른 사용자 프로세스로 CPU 제어권을 넘기기 위한 목적이 있으므로, 이경우 반드시 context switch가 일어남
    • I/O request system call 등 오래 걸리는 요청이 들어왔을 경우, 해당 프로세스로 CPU를 다시 할당해도 할 수 있는 일이 거의 없으므로 다른 사용자 프로세스로 CPU를 넘기기도 함

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

  • 프로세스들은 각 큐들을 오가며 수행됨
  • queue에는 PCB가 줄서있음 (PCB에 있는 pointer를 이용해서)

큐의 종류

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

스케줄러 (Scheduler)

스케줄러의 종류

  • Long-term scheduler(장기 스케줄러 or job scheduler)
    • 프로세스에 메모리를 주는 문제
    • degree of multiprogramming(메모리에 올라가 있는 프로세스의 수)을 제어
      • 메모리에 너무 많은/적은 프로그램이 동시에 올라가면 컴퓨터 전체의 성능이 안좋아짐 (이전 강의 참고)
    • time sharing system의 경우 보통 장기 스케줄러가 없음 (무조건 ready)
      • 그러면 time sharing system은 degree of multiprogramming을 어떻게 제어하는가? : Medium-term scheduler
  • Short-term scheduler(단기 스케줄러 or CPU scheduler)
    • 프로세스에 CPU를 주는 문제 : 다음번에 어떤 프로세스에 CPU를 줄 것인가?
  • Medium-term scheduler(중기 스케줄러 or Swapper)
    • 장기스케줄러는 프로그램 시작 시 메모리를 줄지 말지 결정
    • 중기 스케줄러는 프로그램 시작 시 무조건 메모리를 부여
      • 메모리에 너무 많은 프로그램이 동시에 올라오는 문제
      • 이를 조절하는 역할을 담당
    • 일부 프로그램을 골라서 메모리에서 통째로 쫓아냄(디스크로 보냄)
      • → degree of multiprogramming 제어
    • 중기 스케줄러로 인해 process state가 하나 추가됨: suspended 상태

참고 링크

KOCW 운영체제 - 이화여대 반효경 교수 (2014-1) 5강

profile
kmjoo
개발 취준생
이전 포스트

[OS] System Structure & Program Execution 2

다음 포스트

[OS] Thread

post-custom-banner

0개의 댓글