- 본 글은 이전에 사용하던 영상 강의 필기 앱인 'Slid'에서 필기 했던 내용을 Velog로 옮긴 내용입니다.
- 본 글은 이화여대 반효경 교수님 2017학년도 1학기 운영체제 강의를 기반으로 작성되었습니다.
- 강의 링크 : http://www.kocw.net/home/search/kemView.do?kemId=1226304
문맥 교환 (Context Switch)
CPU는 매우 빠르기 때문에 짧은 간격으로 여기 저기 프로세스를 돌아다니며 소유권을 점유당한다. 이 때 뺏겼다가 다시 얻었을 때는 뺏겼던 시점의 문맥을 기억했다가 계속 이어서 해주는 메커니즘이 필요하게 된다. 그 때 문맥 교환이 필요한데 이때 CPU에 존재하던 해당 프로세스의 정보들, 해당 프로세스의 PCB에 저장하며, PC와 memory map도 저장한다. 여기서 주의할 것은 프로세스의 문맥은 프로세스 A(현재 프로세스)의 PCB, 즉, 메모리에서 커널이 관리하는 데이터 영역에 저장하게 된다. 운영체제가 PCB로 프로세스를 관리하니까 당연히 PCB에 그 정보를 저장할 것이다. 아무튼 이 문맥 교환은 두 가지 양상이 존재한다.
첫 번째, 일반적으로 문맥 교환은 사용자 프로세스 간에 일어나는 일이다. System call을 본인이 했거나 interrupt가 외부로부터 들어왔다면 cpu 제어권은 운영체제 kernel로 넘어간다. interrupt라면 interrupt service routine을, system call이었다면 관련된 커널의 함수를 실행하게 된다. 이 경우에는 다른 프로세스로 넘어간다고 표현하지 않는다.
두 번째로는, timer interrupt나 I/O system call이라면 오래 걸리는 작업이므로 다른 프로세스로 넘어간다. 첫 번째 양상도 어느 정도 save를 하고 kernel로 넘어가야 하지만 2번보다는 overhead가 훨씬 적다. 즉, 두 번째와 같은 문맥 교환이 일어나게 되면 cache memory flush와 같은 작업들을 실행해야 하는데 이것의 overhead가 첫 번째보다 훨씬 크다.
프로세스 스케줄링 큐(Process Scheduling Queue)
이미 프로세스의 문맥 교환 과정이 어떻게 일어나는지 충분히 설명했다. 프로세스 스케줄링 큐는 이 문맥 교환 과정에서 발생하는 CPU 소유권 쟁탈전을 관리하기 위해 만들어진 것으로 본 강의에서는 쉽게 이해하고 넘어가면 된다. 프로세스 스케줄링 큐에는 크게 세 가지가 있다. Job queue는 모든 프로세스를 담고 있는 큐이다. Ready queue는 Process state에서 Ready인 상태의 프로세스를 모아둔 것이다. Device queue는 I/O device마다 device를 점유하기 위해 모인 프로세스들을 관리하기 위해 만든 큐이다.
그런데 앞서 프로세스의 관리는 커널에서 'PCB'라는 자료 구조를 통해 이루어진다고 하였다. 따라서 이를 이해하기 쉽게 도식화하면 다음과 같다.
스케줄러(Scheduler)
스케줄러에는 세 가지가 있다. 단기(Short-term), 중기(Medium-term), 장기(Long-term) 이렇게 세 가지이다. 이것을 조금 더 구체화해보자.
1. CPU 스케줄러 (Short-term scheduler) : 밀리초 단위로 스케줄링 하며 다음에 어떤 프로세스를 실행할지를 관리한다.
2. Job scheduler (Long-term scheduler) : 어떤 프로세스에 메모리를 줄지를 관리한다. 아래 그림을 참조하자. 여기서 admit는 메모리에 올라갈 것을 허락하는 과정이다. 따라서 Degree of Multiprogramming을 제어하게 된다.(Multi-programming은 메모리에 여러 프로그램이 동시에 올라가는 개념). 메모리에 올라가는 프로세스의 수를 제어해야 하는데 이때 너무 많은 프로그램이 올라가도 안좋고, 적어도 효율이 떨어진다. 너무 많으면 메모리에 너무 조금씩만 있기 때문이다. 그러나 최근 time sharing system에는 일반적으로 Job scheduler, 즉, 장기 스케줄러가 없고 모두 ready queue에 넣는다.
3. Swapper (medium-term scheduler) : 메모리에 너무 많은 프로세스가 올라와 있으면 디스크로 쫓아낸다. 원래 장기 스케줄러(Job scheculer)가 있었을 때는 애초부터 적절한 degree of Multiprogramming을 제어했었는데, 지금의 시스템은 장기 스케줄러가 없기 때문에 swapper가 제어한다. 이것 때문에 새로이 생긴 프로세스의 상태가 suspended이다.
* Suspended(**빼앗긴** 프로세스의 상태**)**
- 외부(중기 스케줄러)에서 정지시킨 것이기 때문에 외부에서 다시 재개해주어야 위에 있는 active한 상태로 넘어갈 수 있게 된다.
- 이것 외에도 ctrl+z 를 누르면 사람이 프로세스 정지시킬 수 있다. 이것도 suspended다. 이때 다시 사람이 프로세스를 재개해야 한다.
프로세스 상태도
프로세스의 상태도를 통해 운영체제가 어떻게 프로세스를 관리하는지 살펴보자.
프로세스가 cpu를 갖고있으면서 본인이 하는 걸 user mode running state라고 한다. 그러나 이때 본 프로세스가 어떤 일을 할 수 없어서 kernel에게 요청할 때(즉, I/O와 같은 작업), CPU의 소유권이 운영체제 커널로 넘어가는데 이때 프로세스가 kernel mode에서 running하고 있는 것이지 운영체제가 running state에 있는 것이 아니다. 추가적으로 Suspended는 메모리를 뺏긴 상태이기 때문에 cpu는 아무 일도 할 수 없으나 원래 하던 I/O작업 등이 있다면 blocked에서 ready로 넘어갈 수는 있다. 나머지 상태는 이전 강에서와 동일하다. (이 부분 이해 잘 안됨)
