프로세스의 개념

프로세스는 실행중인 프로그램을 말한다.

프로세스의 문맥 Context

CPU 제어권이 돌아왔을 때 이걸 보고 이어서 한다.
현재 시점 및 현황 파악용

1. 하드웨어 문맥 : CPU 수행 상태
   program counter(어디를 수행 중인지), regitsters(어떤 값이 들어있는지)
2. 프로세스의 주소 공간 : 메모리 관련
   code, data, stack (어떤 내용이 들어있는지)
3. 프로세스 관련 커널 자료 구조 : 프로세스 관리 관련 (OS가 사용)
   PCB, Kernel stack

프로세스의 상태 Process State

CPU가 하나이기 때문에 프로세스 관리 측면에서 상태를 통해 관리한다.

• Running : CPU가 수행 중인 상태

• Ready : CPU만 만족하면 되도록 모든 준비(메모리)를 마치고 CPU를 기다리는 상태

  ➡️ 이 두 상태를 교환하면서 CPU 나눠씀

• Blocked (wait, sleep)
  CPU를 주어도 당장 수행될 수 없는 상태
  자신의 event (I/O)가 만족되지 않아 기다리는 상태

필수 x 상태
1. new : 프로세스가 생성중인 상태
2. Terminated : 수행이 끝난 상태 ➡️ 할일은 끝났지만 정리하는 중, 종료 중인 상태

상태도

Queue

모든 자원이 놀지 않도록 queue를 통해 정리

• CPU ⬅️ Running
  • Ready queue ⬅️ Ready
• 공유 데이터 SW 자원
  • Resource queue ⬅️ Blocked
    프로세스 여러 개가 동시에 접근하면 안됨. 그래서 queue
• I/O device
  • ${device} queue ⬅️ Blocked

[예시]
한 프로세스가 disk 읽어오기 작업이 필요하면, blocked 상태가 되어 Disk I/O queue로 이동한다. 자신의 차례가 되어 Disk에서 작업을 처리하고 controller을 통해 Interrupt을 걸면 OS가 제어권을 얻고, 해당 프로세스를 Ready queue로 이동시킴.

Queue들은 OS가 프로세스 관리를 위한 stack, data, code가 있는 Kernel Address space인 PCB의 Data에 있다.

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

프로세스는 각 큐들을 오가며 수행됨

• Job Queue
  아래 두 큐를 포함해 현재 시스템 내에 있는 모든 프로세스의 집합

• Ready Queue
  현재 메모리 내에 있어 실행되기를 기다리는 프로세스의 집합

• Device Queue
  I/O device의 처리를 기다리는 프로세스의 집합

➡️ 정확히는 OS가 프로세스를 관리하는 자료구조인 PCB를 줄 세우는 것이다.

PCB

Process Control Block
OS가 각 프로세스를 관리하기 위해 각 프로세스 별로 유지하는 정보

구성요소

1. OS 관리상 사용하는 정보
   • Process state, Process ID
   • scheduling information, priority ➡️ CPU를 주기 위한 우선순위나 스케줄링 정보
2. CPU 수행 관련 하드웨어 값 : HW context
   • Program counter, registers
3. 메모리 관련 : Memory context
   • code, data, stack 위치 정보
4. 파일 관련 : 어떤 것을 open 하는지, 그 외 resource 정보

문맥 교환 Context Switch

CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정

이때 OS가 하는 일

1. 원 프로세스의 상태를 그 프로세스의 PCB에 저장 ➡️ 문맥을 저장하고
2. 새롭게 얻는 프로세스 상태를 PCB에서 읽어옴 ➡️ 문맥을 읽어오고

system call이나 interrupt시 반드시 일어나는 일은 아니다.

1. 문맥 교환 X
   A 프로세스 유저 모드에서 커널 모드로 갔다가 다시 A 프로세스 유저 모드로 복귀함
2. 문맥 교환 O
   A 프로세스 유저 모드에서 커널 모드를 지나 문맥 교환 후 B 프로세스 유저 모드로 변경

➡️ 1도 context의 일부를 저장하긴 하지만 2번처럼 문맥 교환이 일어나는 경우가 오버헤드가 상당함

스케줄러 Scheduler

• Long-term scheduler (현재는 사용하지 않음)
  장기 스케줄러, Job scheduler
  메모리에 프로세스 몇개인지를 관리, 애초에 올라가기 전에 프로세스 수를 관리
  • 시작 프로세스 중 뭐를 Ready 큐로 보낼지 결정
  • 프로세스에 메모리를 주는 문제
    new -> ready 로 넘어갈 때 메모리 올라가는 허락 admitted이 필요함
  • time sharing system에는 해당 스케줄러 x
• Short-term scheduler
  단기 스케줄러, CPU scheduler
  • 다음 번에 어떤 프로세스를 running 할지 결정
  • 짧은 시간 단위, 충분히 빨라야 함
  • 프로세스에 CPU를 주는 문제
• Medium-term scheduler (현재 사용)
  중기 스케줄러, Swapper
  올라간 후 프로세스 수 관리
  • 시작하자마자 무조건 메모리에 올려주고 이 이후를 관리
  • 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아낸다.
  • 프로세스에게서 memory를 뺏는 문제
  • Suspended 상태 사용
    외부에서 강제로 정지 시켜 디스크에서 swap out된 상태.
    blocked와 다름
    
    running에 유저 모드, 커널 모드 두 가지가 있음
    suspended도 이에 맞춰 두 가지로 나뉨
    • Suspended Blocked : swap outed, 메모리도 잃은 상태
    • Suspended Ready

Thread

프로세스 내부에 여러 CPU 수행단위인 Thread가 존재할 수 있음
Lightweight process 방식
전통적인 heavyweight process는 하나의 thread를 가진 task로 볼 수 있음

특징

프로세스 여러 개 보다 스레드 여러 개 두는 것이 낫다!
같은 일을 하는 프로세스를 여러개 두면 메모리 낭비
➡️ 주소공간을 하나 두고 각 일마다 구역을 나눈다 : Task
한 프로세스 내에서 스레드 끼리 공유할 수 있는 부분을 최대한 공유하는 것

구성 Thread가 독립적으로 갖는 것
Program counter, Register set, Stack space
➡️ CPU 관련 정보

Thread가 공유하는 부분 = Task
code section, data section, OS resources

장점

1. 하나의 스레드가 block되어도 다른 스레드가 빠르게 running 하여 빠른 반응을 할 수 있음 ➡️ 빠른 응답 가능
2. 동일 일 수행하는 스레드가 협력하여 높은 throughtput과 성능 향상이 있음
3. 각 스레드들이 다른 CPU 부분에서 일을 동시에 해 결과를 더 빨리 얻음 ➡️ 높은 병렬성

Benefits of Thread

• Responsiveness 응답성
  할 수 있는 것 하고 있기
  하나가 blocked 돼도 다른 하나라도 수행 가능
• Resource Sharing 자원 공유
• Economy 경제성
  좀더 빠르다. overhead가 심하지 않다.
  creating, cpu switching이 thread끼리 일어나면 빠르다.
  그래서 같은 일을 할 때 모아두면 효율적이다.
• Utilization of MP Architectures ➡️ CPU가 많을 때 장점
  parallel하게 각 processor에서 수행됨

Implementation of Threads

• supported by kernel : Kernel Threads
  스레드가 여러 개인 것을 OS가 안다.
  windows95/98/NT, Solaris 등
• supported by library : User (level) Threads
  OS는 스레드가 몇개인지 모르고 user program이 스스로 관리한다.
  구현상 제약점이 있음
  POSIX Pthreads, Solaris threads

리얼 타임 스레드도 있음

Process Management

프로세스 생성 Process Creation

부모 프로세스가 자식 프로세스를 문맥 '복제'를 통해 생성 ➡️ 트리 구조를 형성하게 됨

자원

실행 하기 위해서 자원이 필요함

• OS로 부터 받기
• 부모와 공유 (원칙은 공유하지 않는 것)
  • 모든 자원을 공유하는 모델
  • 일부를 공유하는 모델
  • 공유하지 않는 모델

종류 : 수행 Execution을 기준으로

• 공존하며 수행 : 경쟁하는 모델
  COW (copy-on-write)
  ➡️ write을 했을 때 copy를 하게 됨, 이때 부터 부모와 공유
  1. 부모의 주소공간 공유❌
  2. Stack에 각자 쓰다보니 한 공간을 자식이 완전히 소유함.
• 자식이 종료될 때까지 부모가 기다리는 모델

주소 공간 Address space

자식은 부모 공간을 복사하고 (fork), 그 공간에 새로운 프로그램을 올린다 (exec).
각 행위는 독립적이고, OS를 통해서 실행됨

프로세스 종료 Process Termination

1. 자발적 종료 exit
   프로세스가 마지막 명령 수행 후 OS에 알림
   - 자식이 부모에 output data를 보냄 wait
   - 각종 자원이 OS에 반납됨
2. 강제 종료 abort
   자원 할당치를 넘기거나, 해당 task가 더이상 필요하지 않을때, 부모가 exit된 경우

종료 원칙: 자식이 먼저 죽어야 한다.

시스템 콜

1. fork()
   부모의 context를 복사해 자식을 생성함
   • id를 부여해 자식, 부모 구분
     • pid=fork()
       return 값으로 구분
       0 > child / 양수 > parent
   • 자식도 같은 PCB를 갖게 되므로 fork 이후 instruction을 수행함
2. exec()
   새로운 프로그램으로 메모리를 덮어씌움
   • execlp("bin/date","/bin/date",(char *)0);
     이를 통해 새로운 main을 갖고 실행하게 됨
   • fork 없이 단독 사용 가능
3. wait()
   커널은 자식이 종료될 때까지 부모를 sleep 시킴 ➡️ block 상태
   자식이 종료되면 커널은 부모를 깨운다 ➡️ ready 상태
   ➡️ 병렬이 아니게 됨.
4. exit()
   프로세스의 종료
   • 자발적 종료 : 암시적 ({})
     마지막 수행 후 exit 시스템 콜을 통해 명시없어도 main 함수가 리턴되는 위치에 컴파일러가 자동으로 넣음
   • 비자발적 종료 : 외부에서 죽이는 것
     • 부모 프로세스가 자식 강제 종료
       • 한계치를 넘어서는 자원 요청, 자식 테스크가 더이상 필요하지 않음
     • 키보드로 kill,break by 사용자
     • 부모가 종료하는 경우 (종료 원칙을 지켜야 해서)

프로세스 간 협력

• 독립적 프로세스 Independent process
  프로세스는 각자 주소 공간을 가지고 수행되므로 서로 수행에 영향을 미치지 못함
• 협력 프로세스 Cooperating process
  협력 매커니즘을 통해 서로 수행에 영향을 미칠 수 있음
  정보를 주고 받는 방식
  • 협력 메커니즘 IPC Interprocess Communication
    • message passing
      커널을 통해 메세지를 전달 (직접 연락 안됨)
    • shared memory
      다른 프로세스 간에도 커널에게 시스템 콜을 보내놓은 뒤 일부 주소 공간을 공유할 수 있음
      각 프로세스는 서로 신뢰가 바탕이 돼야 함
    • thread 완전한 협력
      사실상 하나의 프로세스이므로 협력이라기보다는 주소 공간을 이미 공유하고 있음으로 협력 가능!

Message Passing

프로세스 사이에 공유 변수 없이 통신하는 시스템
종류 (둘다 커널을 거쳐야하는 공통점, 인터페이스 측면의 구분)
1. Direct Communication
통신하려는 프로세스 이름을 명시적으로 표시
P: send(Q,message) -> Q: receive(P,message)
2. Indirect Communication
mailbox or port로 메시지 간접 전달. 이름을 명시하지 않아 누구나 받을 수 있음

CPU Scheduling

프로그램은 CPU burst와 I/O burst의 반복으로 번갈아 수행된다.
다만, 그 빈도와 길이가 다르게 된다.
빈도가 높으면 burst의 길이가 짧고, 빈도가 낮으면 burst의 길이가 길다.
Interactive Job이 주로 반복 빈도수가 높은데 이는 적절한 response가 제공돼야 하기 때문이다.
시스템 자원을 형평성있게 효율적으로 사용하기 위함이다.

프로세스의 특성 분류

• I/O-bound process : many short CPU bursts
  CPU보다 I/O에게 많은 시간이 필요한 job. 전환 빈도수가 높고 CPU burst가 짧음
• CPU-bound process : few very long CPU bursts
  계산 위주 즉 CPU 위주의 job. 전환 빈도수가 낮고 CPU burst가 긺

CPU Scheduler & Dispatcher

• CPU Scheduler : OS 내부에 코드가 존재
  "누구에게 줄것인가" Ready 상태 프로세스 중 CPU를 줄 프로세스를 고른다
• Dispatcher : OS 안에 특정 기능을 하는 코드 존재 ➡️ 넘겨주는 역할
  CPU 제어권을 CPU scheduler에 의해 선택받은 프로세스에게 넘긴다.
  Context Switching

CPU 스케줄링이 필요한 이유는 상태 변화가 있을 때이다.

• Nonpreemptive : 강제로 뺏지 않고 자진 반납
  • Runnung ➡️ Blocked : I/O 요청 시스템 콜
  • Terminate : 프로세스 종료로 CPU 넘어갈 때
• Premptive : 강제로 빼았음
  • 다른 모든 스케줄링
    • Running ➡️ Reday : 할당 시간 만료로 Time interrupt
    • Blocked ➡️ Ready : I/O 완료 후 인터럽트