02. Processes
프로세스란?
1. 운영체제의 이해를 위한 기본 개념
2. 멀티프로그래밍(Multiprogramming)의 기본 단위
3. 스레드(thread)와 비교 필요
4. 정의: A program in execution(실행중인 프로그램), 컴파일러에 의해 프로그램을 실행파일로 컴파일 -> 로더에 의해 실행파일을 메모리에 탑재 -> 실행되는 순간 프로세스가 됨!
실생활에서의 프로세스 예
1. 프로세스는 “a sequence of snapshots”로 눈에 보이지 않음(Invisible). 그러나 관리가 이루어져야 한다.
2. 수행의 실재는 프로그램이 조작하고 있는 데이터의 상태(state) 시간에 대한 변화를 기반으로 프로세스를 관리한다
3. 데이터의 상태(state) 정보: 실행 위치(Program Counter, PC), 스택 포인터(Stack Pointer, SP) 등
메모리 상의 프로세스 구성
1. 프로세스의 구성
① 프로그램 계수기(Program counter, PC): 다음에 실행할 프로그램의 위치를 저장하고 있는 특별한 CPU register(cpu 안에 있음), PCB에 포함
② 스택(stack): 스택 포인터(Main Memory안에 있음), PCB에 포함
③ CPU register: PCB에 포함
④ 데이터(data section): 데이터 내용(ublock 안에 있음)
프로세스 상태
1. 프로세스는 수행되면서 상태가 바뀜
2. 이 상태는 연속적이지 않고 이산적
3. 상태 변화를 일으키는 이벤트
① Interrupt by time: time slice(time slot)의 시간이 경과했음을 알려주는 event
② dispatch: scheduler에 의해 ready queue로부터 적절한 프로세스를 선택하여 cpu를 할당
③ I/O wait: 어떤 프로세스가 I/O에 들어갈 경우 장시간 걸리는 I/O 동안 block 됨(swap-out)
④ I/O 완료었다는 event 발생
4. 프로세스 상태
① Running: acutally using CPU at that instant(실제로 CPU를 사용하여 실행하고 있는 상태)
② Ready: Runnable, temporarily stopped to let another process run(실행 대기중)
③ Blocked(Waiting): Waiting, unable to run until some external event happens(외부의 이벤트가 일어날 때까지 기다리고 있는 상태). e.g. I/O
④ New: the process is being created(처음에 프로세스가 만들어졌을 때)
⑤ Terminated: the process has finished its execution(프로세스가 종료되었을 때)
Four possible transition(상태 변이를 일으키는 4가지 액션)
1. dispatch: ready -> running
2. timerrunout: running -> ready
3. block: running -> blocked
4. wakeup: blocked -> ready
5. blocked 상태로의 진입만 자신에 의해서 일어나고 나머지 상태 변이는 해당 프로세스의 외부 event에 의해 일어남
Process Implementation
1. process control block(PCB)
① a data structure storing complete information about process(프로세스의 모든 정보를 갖고 있는 데이터 구조)
② Unix에서는 이를 u_block으로 정의
③ 성능 저하를 일으키는 요인 중 하나
④ 프로세스 당 하나씩 있음
2. Process table
① array of PCBs
3. PCB에 저장되는 정보
① 프로그램 카운터의 내용(Program Counter)
② 프로세서 상태 워드(PSW): CPU의 상태
③ 레지스터 내용
④ 스택 포인터
⑤ 메모리 관리 내용(Memory management)
⑥ 파일 시스템에 관한 내용: ex)root, working directory …
Schedulers
1. 프로세스 관리의 핵심
2. 스케줄러가 동작하는 빈도 수에 따른 3가지 유형
① Long-term Scheduler(Job Scheduler): 수행 빈도수가 가장 낮음, 지금은 잘 안씀
② Medium-term Scheduler(Swapper): 메인 메모리 내용을 디스크로 넣는게 swap-out, 디스크에 있는 내용을 메모리에 넣는게 swap-in. 중간 정도 빈도수
③ Shor-term Scheduler(CPU Scheduler): 수행 빈도수가 매우 높음
Long-term Scheduler(JOB Scheduler)
1. Shor-term Scheduler보다 훨씬 낮은 빈도수로 수행된다
2. 대용량 저장 장치에서 수행을 기다리고 있는 프로세스들을 schedule 한다. (process pool(대용량 저장 장치에서 ready-queue로 올라가길 기다리공고 있는 프로세스 집합)에서 기다리고 있는 프로세스들 중 선택)
3. multiprogramming의 정도(degree of multiprogramming)를 제어
- degree가 steady하다면 (multiprogramming의 정도가 일정 수준을 유지한다는 뜻): 컴퓨터 시스템 내부로 들어오는 프로세스의 수의 비율 == 실행이 끝나서 시스템을 떠나는 프로세스의 수의 비율
4. For the best performance: I/O-bound(I/O가 주로 필요한 프로세스) 와 CPU-bound(CPU가 주로 필요한 프로세스)의 혼합이 필요함
5. 보통 time-sharing 시스템에서는 long-term Scheduler는 필요없음. 사용자들이 스스로 process pool을 만들어 감
Medium-term Scheduler (Swaper)
1. 키보드 입력을 받아야 하는데 입력이 계속 안될 때 디스크 쪽으로 저장. 다시 입력이 시작 될 때 디스크에서 빼와서 다시 실행
2. 주로 입출력 할 때 일어남
Short-term Scheduler
1. 여러 개의 프로세스를 실행하기 위해 프로세스를 바꿔주는 스케쥴러
Context Switch
1. Context Switch: switching the CPU to another process requires saving the state of the old process and loading the saved state fot the new process. CPU를 다른 프로세스로 할당(Switching)하는 것. 이전 프로세스의 PCB를 저장(state save)하고 나서 새로 실행할 프로세스의 PCB를 메모리에 읽어옴(state restore).
2. Overhead: Context Switching 시간
3. Processing Thrashing: Time Slot Tc가 Context Switching 시간 t보다 짧아서 프로세스는 수행되지 않고 Context Switching만 일어나는 것
4. 반드시 Tc < t여야 프로세스의 진전이 일어남,
5. Overhead는 지원하는 H/W에 따라 커다란 차이를 나타냄.
① 사용된 메모리의 읽고 쓰는 속도 (memory access time/cycle time)
② CPU내부의 register 개수
③ CPU가 Context Switch와 같은 동작을 하는데 유용한 특수한 인스트럭션을 가지고 있느냐의 유무
④ 메모리 관리(memory menagement) 기법
6. 이 Context switch에 들어가는 Overhead가 시스템 성능의 병목 현상을 일으킬 수 있음. 이 문제를 해결하기 위해 Thread라는 개념이 나옴(Context의 사이즈를 대폭 줄임).
Context Switch 단계
1. 지금 Context Switch가 일어나야 하는지 결정, Context Switch가 가능한지 결정
2. 현재 실행중인 Process의 Context Save
3. 프로세스 스케줄링 알고리즘을 사용하여 실행하기에 best인 process를 찾음
4. 그 프로세스의 context를 저장함
5. 간소화된 scheduler의 구조
Process Switch vs Context Switch
1. Process Switch: Context Switch를 포함하여 스케줄링 알고리즘을 실행하여 Process를 선택하고 그 Process가 완전히 전환되기까지의 시간.
2. Context Switch: Context가 state save, state restore하는 데 걸리는 시간
Thread
1. Process
① 각 프로세스는 독자적인 주소 공간을 쓰고 있음
② 1번의 이유로 Heavy weight process
③ 대부분의 폐쇠적인 운영체제가 이런 프로세스 개념을 갖고 있음
2. Thread
① 프로세스를 구성하는 더 작은 단위의 프로세스 단위(aka.task)
② CPU가 수행하는 데에 가장 기본적인 단위
③ Thread Control Block이 있으나 매우 크기가 작음 (공유하는 Data가 많아서)
④ PC(Program Counter), Register set, Stack Space는 공유가 안되므로 TCB에는 이 세 개만 들어감
⑤ 같은 주소 공간, 메모리 관리 정보, 리소스 정보 등을 공유
⑥ Thread끼리는 독립적이지 않아서 다른 Thread의 내용을 수정할 수 있음(보호되지 않음)
⑦ 2 Type of Thread
- Kernel Level: O.S Kernel의 지원을 받는 Thread. System call이 많아질 수 있어서 성능이 나빠질 수 있음
- User Level: Kerenl 위에서 지원을 받는 Thread . ex) JVM위의 Java Thread
⑧ Thread는 2개 이상의 CPU를 가진 다중 프로세스 시스템에 적합함
User Level Thread
1. User Level의 User Level Libraries에 내장되어 있음
2. thread switching은 O.S의 도움을 필요로 하지 않음(Kernel로 Interrupt가 발생하지 않음)
3. 2는 곧 O.S가 Thread를 감지하기 못하고 있다는 것을 의미함. 그러므로 Thread간 Switching은 전적으로 User-Level에서 책임지고 이루어져야 함
4. 그러므로 Thread들 간의 Switching은 O.S와 무관하게 일어나므로 매우 빠르게 진행될 수 있음
5. 그러나 Scheduling이 불공평하게 일어날 수 있음
6. 만약에 Kernel이 하나의 Thread로 구성되어 있다면(Single-threaded), System call을 수행하는 User-Level Thread는 현재 수행중인 System call이 완료될 때 까지 전체 테스크를 지연시키게 됨.
7. 100 Threads vs 1 Threads
Kernel-Level Threads
1. Kernel이 Thread를 인지하고 있으며, Thread 단위로 Scheuling 함
2. Multiple-Thread of control(O.S(Kernel)가 여러 개의 Thread로 이루어져 있음)환경에서 resource의 사용 측면에서 더욱 효율적임.
3. Kernel 자체가 여러 개의 Thread로 구성되어 있을 경우(Multiple-Thread of control), 어떤 User-Level Thread가 Resource 사용을 위해 System call을 수행하고 있을 경우 해당 Resource를 사용하지 않는 다른 Thread의 System call은 병렬로 수행할 수 있음. ex) 디스크 담당 Thread, 프린터 담당 Thread가 있다고 할 때 동시에 같이 처리할 수 있음
6. 최근 운영체제는 User-Level Thread와 Kernel-Level Thread 모두 지원
7. 100 Threads vs 1 Thread
