Process Management
Job Vs Process
비교하기
▷ Job
Job이라는 것은 우리가 짠 프로그램과 그 프로그램이 처리하는 데이터를 묶어둔 것이다.
간단하게 프로그램이라고도 부른다.
이 Job은 현재 디스크에 보관되어 있는 상태를 말하며, 컴퓨터 시스템에서 실행하려고
요청하기 전의 상태이다.
▷ Process
프로세스란 실행을 위해 시스템(커널)에 등록된 Job(=Program)으로 정의할 수 있다.
다른 말로는 시스템에 등록되어 메모리를 할당 받은 Job(=Program)을 말한다.
커널에서 관리하는 이유는 시스템 성능 향상을 위해서이다.
프로세스의 정의는 아래와 같이 알아두도록 하자.
• 커널에 등록되고 커널의 관리하에 있는 작업
• 각종 자원들을 요청하고 할당 받을 수 있는 개체
• 프로세스 관리 블록(PCB)을 할당 받은 개체
• 능동적인 개체 → 실행 중에 각종 자원을 요구, 할당, 반납하며 진행
자원(Resource)의 개념
• 커널의 관리하에 프로세스에게 할당/반납 되는 수동적 개체
• 컴퓨터에 속해 있는 프로그램이나 하드웨어의 구성요소인 CPU, 메모리, 디스크 등
분류 | 종류 |
---|---|
하드웨어 | 프로세서, 메모리, 키보드, 마우스 등등 |
소프트웨어 | 설치된 소프트웨어, 파일들 |
Process Controll Block(PCB)
PCB란?
• OS가 프로세스 관리에 필요한 정보를 저장한다.
• 프로세스 생성 시, 커널 영역에 생성된다.
PCB가 관리하는 정보
정보 | 설명 |
---|---|
PID (Process Identification Number) | 프로세스 고유 식별 번호 |
스케쥴링 정보 | 프로세스 운선순위 등과 같은 스케줄링 관련 정보들 |
프로세스 상태 | 자원 할당, 요청 정보 등 |
메모리 관리 정보 | Page table, segment table 등 |
입출력 상태 정보 | 할당 받은 입출력 장치, 파일 등에 대한 정보 등 |
문맥 저장 영역(context save area) | 프로세스의 레지스터 상태를 저장하는 공간 |
계정 정보 | 자원 사용 시간 등을 관리. |
프로세스의 상태
프로세스의 라이프 사이클을 도식화한 그림이다. 이번 섹션에서는 아래의 과정을
하나하나 뜯어서 살펴볼 것이다.
⒈ Created State (생성된 상태)
• 작업(Job)을 커널에 등록
• PCB할당 및 프로세스 생성
이 때 커널은 가용 메모리 공간 을 체크한다. 할당할 메모리가 있다면 Ready상태로,
없다면 Suspended Ready 상태로 프로세스의 상태를 전이시킨다.
⒉ Ready State
• Processor(=CPU) 외에 모든 자원을 할당 받은 상태
• Processor(=CPU) 할당 대기 상태
• 즉시 실행 가능 상태
이렇게 Ready state에서 CPU할당을 기다리고 있다가 CPU를 할당 받으면 Running state로
올라가게 되는데 이것을 Dispatch 됐다
또는 schedule 됐다
라고 표현한다.
⒊ Running State
• Processor(=CPU)와 필요한 자원을 모두 할당 받은 상태
Running state에서 벗어나는 경우는 Preemtion, Block/Sleep 이렇게 두 가지가 있다.
▷ Preemtion
Preemtion
은 Running에서 Ready로 내려가는 경우이다.
Ready 상태는 Processor(=CPU)만 없는 상태이다.
즉, Processor(=CPU)를 뺏기면 다시 Ready상태로 내려가는 것이다.
▷ Block/Sleep
Block/Sleep
은 Running에서 asleep으로 내려가는 경우이다.
예를 들어 보자. 은행 업무를 보러갔는데 필요한 서류를 두고 왔다면?
다시 집에 돌아가서 해당 서류를 들고 와야한다. 하지만 해당 창구에 잠시 기다려달라고
요청할 수는 없다. 왜냐면 뒤에 대기하고 있는 수 많은 대기자들이 나를 위해서 기다려야
하기 때문이다.
이처럼 I/O등 자원 할당 요청이 들어올 경우 Ready에서 프로세서 할당을 기다리는
등록된 Job
들을 위해 프로세서를 반납해야 한다.
⒋ Blocked/Asleep
• 프로세서 외에 다른 자원을 기다리는 상태
• 자원할당은 System Call에 의해서만 이루어진다.
I/O를 위해 asleep으로 내려간 상태에서 필요한 데이터가 할당 됐다면, 바로 다시
Running State로 올라가도 될까? 절대 그래선 안된다.
왜냐면 데이터를 받아오는 시점에 이미 다른 프로세스가 Running 상태에서 올라가
있기 때문이다. 따라서 I/O가 끝났다면 다시 Ready 상태로 돌아가게 되는데 이것을
wakeup 된다
라고 표현한다.
⒌ Suspended State
• 메모리를 할당 받지 못한(빼앗긴) 상태
Ready 상태에서 메모리를 할당 받지 못하면 Suspended Ready 상태로 내려가고,
Asleep 상태의 경우에는 Processor(=CPU)와 메모리를 모두 빼앗기고 Suspended
Blocked 상태로 내려간다.
그리고 메모리를 빼앗기는 이슈는 커널 또는 사용자에 의해 발생한다.
아마 커널에 문제가 있어 커널이 메모리를 빼앗는 경우가 있을 수도 있고,
사용자가 강제로 CPU를 종료해서 생길수도 있지 않나라고 생각이 든다.
메모리를 빼앗기고 시간이 지나서 다시 해당 프로세스를 진행하려고 할 때,
어디까지 진행했는지 기억을 못하다면 처음부터 다시 일을 진행해야 한다.
그러나 이 것은 좋지 못한 방법이다. 이런 문제를 Swap - Device 가 해결해준다.
Swap-Device는 프로그램 정보 저장을 위한 특별한 파일 시스템이다.
suspended 영역으로 내려가기 전 프로세스의 마지막 작업을 Memory Image
로
만들어서 Swap-Device에 저장한다.
다시 active 영억으로 프로세스가 복귀하면 Swap-Device에 저장되어 있던
Memory Image
를 가져오는데 이런 과정을 Swap-In 이라고 부른다.
반대로 Swap-Device에 저장하는 과정을 Swap-Out 이라고 한다.
⒍ Terminated / Zombie State
• 프로세스 수행이 끝난 상태
• 모든 자원 반납 후인 상태
• 커널 내에 일부 PCB 정보만 남아 있는 상태.
굳이 terminated 상태를 거쳐가는 이유는 아래와 같다.
커널이 이 프로세스가 어떻게 살아왔고, 어떤 자원을 할당 받아서 어떤 일을 했는지
기억을 한다면 다음에 비슷한 일을 하는 프로세스가 들어왔을 때 해당 프로세스를
좀 더 효율적으로 관리할 수 있기 때문이다.
한 마디로, 커널이 PCB 정보를 수집하기 위해 terminated 상태를 거쳐가는 것이다.
프로세스 관리를 위한 자료구조
• Ready Queue : 프로세서 할당을 기다리는 작업들의 Queue
• I/O or Device Queue : Asleep 상태에서는 자원 별로 Queue를 따로 관리한다.
인터럽트(Intrrupt)
예상치 못한, 외부에서 발생한 이벤트
인터럽트 종류
• I/O Interrupt
• Clock Interrupt
• Console Interrupt
• Program Check Interrupt
• Machine Check Interrupt
• Inter - process Interrupt
• System Call Interrupt
인터럽트 처리과정
⒈ 인터럽트 발생
⒉ 커널이 개입 하여 프로세스를 중단시킨다.
⒊ 발생한 인터럽트 처리
3번째 단계에서는 두 개의 과정이 일어난다.
▷ Interrupt Handling
이 과정에서는 인터럽트 발생 장소와 원인을 파악한다.
그리고 파악한 원인을 바탕으로 해당 인터럽트를 무시할지 처리할지 선택한다.
▷ Interrupt Survice
Interrupt Handling에서 적절한 조취를 취하겠다고 결정을 했다면
Interrupt Service Routine을 호출한다.
Context Switching(문맥 교환)
Context
Context는 프로세스가 처리하고 있는 흐름을 의미한다.
프로세스와 관련된 정보들의 집합이라고 하며, CPU 내부 Register 메모리 영역에 있는
값들을 CPU Register Context라고 하고, 그 외에 다양한 정보들은 Main Memory안에
저장이 되어 있을 것이다.
Context switching(= process switching)
• Context Saving : 현재 프로세스의 Register Context를 저장하는 작업
• Context restoring : Register Context를 복구하는 작업
• Context Saving + Context restoring
• 커널의 개입으로 이루어진다.
Context Switch Overhead
Context Switch Overhead는 Context Switching에 소요되는 비용으로
OS마다 다르고, 자주 일어나기 때문에 OS성능에 큰 영향을 준다.
여기서 핵심은 불필요한 Context Switching을 줄이는 방법을 생각하는 것이며,
이를 해결하는 방법으로는 스레드(thred) 가 있다.