02 - 프로세스

SeomIII·2021년 10월 22일
시스템 소프트웨어 중간
0

시스템소프트웨어

목록 보기
2/4

📌 프로세스

: 운영체제를 이해하기 위한 가장 기본적 개념
: 멀티프로그래밍의 기본 단위 / thread와 비교필요

: A program in execution -> 실행 중인 프로그램

  • 프로세스는 무엇인가 action이 일어나고 있음을 알려준다.
  • 프로그램 수행은 invisible 하다. 그러나 관리가 이루어져야 한다.
    invisible한 것을 visible로 간주할 수 있는 것은 무엇일까?

    ==> PCB (program control block)

    : 프로세스를 구현한다 / 정보화 한다

📚 PCB

  • 운영체제가 프로세스에 대한 중요한 정보를 저장해 놓을 수 있는 저장 장소
  • 운영체제가 프로세스 스케줄링을 위해 프로세스에 관한 모든 정보를 가지고 있는 데이터베이스
  • 프로세스가 생성될 때마다 고유의 PCB가 생성되고, 프로세스가 완료되면 PCB는 제거됨

    1. program counter (pc) : 다음에 실행해야할 명령어의 주소를 가리킴
    2. stack pointer (sp) : 다음에 실행해야할 프로그램의 위치 저장 (pc의 내용, 기타 필요한 내용들이 stack에 저장됨)
    3. 프로그램이 쓰고 있는 데이터의 내용
    4. cpu안 레지스터의 내용
      • 프로세스의 상태 / 프로세스 id / cpu scheduling information / 파일 시스템에 관한 정보 / 메모리 관리를 위한 내용 등 을 포함하고 있음

📌 Process States

  1. RUNNING : 프로세스가 실행되고 있는 상태

  2. READY : 프로세스가 cpu에 실행되기 위해 ready queue에 대기하고 있는 상태 / 아직 cpu를 받지는 않았지만 cpu를 할당받으면 바로 실행 가능한 상태

  3. BLOCKED (Waiting) : 외부의 이벤트가 발생하길 기다리는 상태

    ex) 프로세스 a가 cpu 할당을 받고 명령어를 실행하다 I/O 작업을 해야하는경우, I/O 작업은 cpu처리 속도에 비해 오래걸리는 작업이기 때문에 프로세스 a는 cpu를 반납하고 (blocked) I/O 작업이 끝나기를 기다린다.

  4. NEW : 프로세스가 막 생성된 상태

  5. TERMINATED : 프로세스가 실행을 완료한 상태

    📌 Four possible transitions

    ++ NEW -> READY : 프로세스가 생성되면 해당 프로세스의 PCB이 OS커널의 ready queue에 올라옴

  • dispatch (READY -> RUNNING)
    : ready queue에 있는 프로세스들 중에서 스케줄링 알고리즘에 의해 선택받은 프로세스가 cpu에 할당을 받는다.

  • timer runout (RUNNING -> READY)
    : cpu를 할당받아 일을 하다 특정 이유로 다른 프로세스에세 cpu를 주고 ready queue에 들어가서 cpu를 기다림

  • block (RUNNING -> BLOCKED)
    : 현재 cpu를 받아 명령어를 수행중이 프로세스가 I/O 작업을 해야하는 경우 cpu를 반납하고 해당 장치 큐에 들어감

  • wake up (BLOCKED -> READY)
    : I/O 작업이 끝났다고 이벤트가 발생되면 BLOCKED 상태였던 프로세스가 다시 ready queue에 들어가게 된다

    ++ RUNNING -> TERMINATED : 프로세스 실행이 완료되어 자원을 반납한다

    • BLOCKED 상태로의 진입, RUNNING-> TERMINATED 만 자신에 의해서 일어나며 나머지 상태 변이는 해당 프로세스의 외부 이벤트에 의해 일어난다!

    📌 Schedulers

  • 스케쥴러가 동작하는 빈도수에 따라 3가지 유형의 스케쥴러

  1. Long-term scheduler (job scheduler)
    : 수행 빈도수가 낮다 (요새는 안씀 _ 사용자가 알아서 결정함)
    : 대용량 저장 장치에서 수행을 기다리고 있는 프로세스들을 schedule 한다
    : I/O-boud(I/O를 많이 가지고 있는 프로세스)와 CPU-bound (I/O가 거의 없고 , 계산 전용) 가 조화롭게 섞여있을 때 가장 좋은 성능을 낸다.

  2. Medium-term scheduler (swapper)
    : 보통 I/O가 너무 오래걸리면 메인메모리에서 디스크로 이동(swap out) 한다

  3. Short-term scheduler (CPU scheduler)
    : 수행 빈도수가 가장 높음

  • 보통 swapper 와 cpu scheduler를 혼합하여 사용함

    📌 Context Switch

    : cpu가 어떤 하나의 프로세스를 실행하고 있는 상태에서 다음 우선순위의 프로세스가 실행되어야 할때 기존의 프로세스의 PCB를 저장하고 cpu가 다음 프로세스를 수행하도록 새로운 프로세스의 PCB를 restore 하는 작업을 context switch라고 한다.

    : process switch time (scheduling 알고리즘이 돌아가는 시간이 포함되어 있음) >= context switch time

  • context switch 하는데 걸리는 시간= Tc , time slot = t 라고 할때,
    Tc > t 이면?
    : 프로세스 실행할 시간이 하나도 없는 것이므로 계속 아무 프로그램도 실행하지 못한다.
    : 따라서 context overhead를 줄여야한다.

    -> 1. context size 를 줄이기
    : 운영체제가 할 수 있다!
    -> 2. context save 시간을 줄이기
    : 하드웨어_ 운영체제에서 어찌할 방법이 없음

    == context overhead를 줄이기 위해 thread 를 사용한다.

    📌 Threads

  • thread 사이에는 공유변수가 존재할 수 있다. 그러나, 프로세스 간에는 공유변수가 존재하지 않는다.

  • 한 프로세스를 몇가지 작은 프로세스로 나눈 것이 thread 이다.

  • light weight process -> 대부분의 데이터를 공유하기 때문에 저장해야할 데이터들이 줄어든다.
    == thread의 상태만 save, restore 하기 때문에 context size를 줄일 수 있다. (pc내용, 레지스터, 스택 만 저장하면 됨.)
    -> context switch 시 overhead가 적어짐.

  • thread들은 서로 간에 독립적이지 않다. (공유 변수)

  • 주소 공간을 공유한다.

  1. kernel-level thread
    : OS가 thread를 인지하고 있으며, thread 단위로 scheduling 한다.
    : kernel 자체가 여러개의 thread들로 구성되어 있을 경우 resource의 사용 측면에서 더욱 효율적이다.

    장) kernel 자체가 여러개의 thread들로 구성되어 있을 경우, 어떤 user-level thread가 system call을 수행하고 있을 경우 해당 resource를 사용하지 않는 다른 thread의 system call은 병렬로 수행할 수 있다. 단) thread마다 system call을 해야하므로 시간이 더 걸릴 수 있다.
    • process A : 100개의 thread로 이루어진 프로세스
    • process B : 1개의 thread로 이루어진 프로세스

      <어떤 프로세스가 더 빠른가?>
      정답: process A가 더 빠르다
      이유: kernel-level thread에서는 os가 thread를 인지해 thread 단위로 scheduling 한다.
      따라서 thread당 t를 할당한다고 가정하면 process A에 100t를 할당하고, process B에 t를 할당하기 때문에 process A 가 더 빠르다.
  2. user-level thread
    : OS가 thread를 감지하지 못한다.
    따라서 thread간의 switching은 전적으로 user-level 에서 이루어져야 한다.

    장) thread 간의 switching은 OS와 무관하게 일어나므로 매우 빠르게 진행될 수 있다.
    단) scheduling이 불공평하게 일어날 수 있다.
    만약 kernel이 single-threaded일 경우, system call을 수행하는 user-level thread는 현재 수행중인 system call이 완료될 때까지 전체 태스크를 지연시키게 된다.
    • process A : 100개의 thread로 이루어진 프로세스
    • process B : 1개의 thread로 이루어진 프로세스

      <어떤 프로세스가 더 빠른가?>
      정답 : process B가 빠르다.
      이유: user-level thread에서는 os가 thread를 감지하지 못해서 process 단위로 scheduling한다.
      process A, B에는 동일한 시간(t)을 할당해주는데, 각 thread에는 A에는 t/100 , B의 thread에는 t를 할당하므로 B가 더 빠르다.

📌 Process creation

  • fork() 를 사용해서 자신과 똑같은 process를 생성한다. (id만 다름)
  • exec() : 부모 process와 다른 일을 할 수 있음.
profile
SeomIII
FE Programmer
이전 포스트

01 _ 운영체제 소개

다음 포스트

03 - CPU Scheduling

0개의 댓글