[운영체제] 이화여대 반효경 교수님 수업 필기 Process1

 

core.ewha.ac.kr/publicview/C0101020140318134023355997?vmode=f

반효경 [운영체제] 5. Process1

 

 

process 란 실행중인 프로그램임.

 

process 의 context 는, 현재 실행중인 process 가 어떤 상태에 있고

어디까지 실행했는지 등을 나타냄.

 

process는 메모리에 개인 주소 공간을 갖고 있고 이곳에 코드(기계어)를 올림.

pc(program counter) 가 process 의 실행 코드(기계어) 어느 부분을 가리킴

pc 가 가리키는 부분에서 코드(기계어)를 읽어서 CPU 안의 레지스터에 저장한 후

ALU(산술 논리 연산장치)에서 처리함.

그 결과를 레지스터에 다시 저장하거나 혹은 메모리에 다시 저장함.

 

따라서 현재 process 가 어디까지 실행했는지 알기 위한 context 를 위해,

pc 가 어디를 가리키는지, 메모리 주소 공간에 어떤 코드와 어떤 함수, 어떤 데이터를 올려두었는지

CPU 레지스터에는 어떤 값을 저장하고 있는가 등을 알아야 함.

이렇게 process 의 현재 상태를 알 수 있는 것을 context 라고 함.

 

 

 

context 는 아래 세가지로 나타낼 수 있음.

- CPU 수행 상태를 나타내는 하드웨어 문맥

 ㄴ CPU 내의 PC(program counter)

 ㄴ CPU 내의 각종 레지스터들

- 프로세스의 메모리 주소 공간

 ㄴ code, data, stack 으로 나타내어지는 공간들

- 프로세스 관련 커널 자료 구조

 ㄴ PCB(Process Control Block) : process 를 관리하기 위해 os 가 갖고 있는 자료구조. 

      os 의 메모리 주소공간 data 영역에 process 별로 하나씩 갖고 있음.

      어떤 process 에게 메모리를 얼마나 줘야 할지, cpu는 얼마나 줘야 하는지 등을 관리

 ㄴ Kernel Stack : process 가 system call 을 했을 때 실행되는 os 함수의 stack 영역

      커널도 함수로 실행되기 때문에 io 등의 system call 을 함수로 실행.

      따라서 함수가 쌓이는 stack 영역에 실행 함수를 쌓아둠.

      이 때 pc 는 process 의 code 를 가리키지 않고 os 의 코드를 가리킴(실행하는 system call 함수 부분)

      process 별로 스택을 다르게 둠. 이를테면 A process 가 실행하는 system call stack 은 23번지에,

      B process가 실행하는 system call stack 은 6674번지에 쌓는 등.

      

 

 

process 는 크게 세가지 상태를 갖음.

 

 

- Running : 현재 CPU 를 잡고 명령을 수행중인 상태

- Ready : CPU 를 기다리는 상태. CPU 만 잡으면 바로 명령 수행이 가능함.

   즉, io waiting 이나 메모리에 코드 올리는 기타 작업들을 이미 모두 마쳐둔 상태.

- Blocked( wait, sleep ) : CPU 를 주어도 명령 수행을 할 수 없는 상태.

   io 응답을 기다리고 있거나,

   메모리에 실행 코드가 바뀌어 올라오고 있을 때(기존 것을 버리고 새로 실행할 코드를 올릴 때) 등

 

이 외 다른 상태도 있음.

- New : 프로세스가 초기에 생성중인 상태

- Terminated : process의 모든 명령 수행이 끝난 상태. 메모장을 닫으면 Terminated 상태가 되겠다.

- Suspended (stopped) : 외부적인 이유로 process 의 수행을 정지한 상태.

   메모리에서 process 의 메모리값들을 모두 disk 로 내쫓은(swap out) 상태.

   즉, 메모리에 페이지가 전혀 올라와 있지 않은 상태

   예를 들어, 메모리에 너무 많은 process 가 올라와 있는 상황에서

   시스템이 process 를 잠시 중단시키기 위해 Suspended 상태로 만든다고 함

   혹은 linux 에서 process 실행중에 Ctrl+Z 를 눌러서 일시정지 시키는 것이 Suspended 라고 함)

 

Blocked 와 Suspended 상태가 헷갈릴 수 있음.

Blocked 는 자신이 요청한 event 가 만족되면 Ready 가 갈 수 있음.

 또한 메모리에 process 가 올라와있음.

Suspended 는 외부에서 resume 해 주어야 Active 가 된다고 함.

 메모리에 process 가 올라와있지 않음.

 

 

참고로, process 가 system call 를 통해 os 에게 cpu 를 넘겼을 때

"os 가 running 상태에 있다" 라고 표현하지는 않음.

단지 유저모드에서 커널모드로 넘어갔다, 커널모드에서 running 하고 있다 라고만 말 함.

위의 이미지에서도 user mode Running 에서 system call, trap 이 발생하면

monitor mode Running 이 되는데 이것을 os 가 running 한다 라고 말 하지 않음.

왜냐면 system call 을 발생시킨 현재 process 가 아직 running 중이란 것을 전제로 하기 때문에.

 

 

 

 

 

os 는 자신의 메모리 주소 data 공간에 Process 의 상태에 해당하는 process 큐를 하나씩 만들어 둠.

예를 들어 running 상태의 process 를 위한 공간

Ready 상태를 위한 큐(cpu 자리가 비면 바로 큐에서 하나 뽑아서 cpu 에 넣을 수 있도록)

Blocked 상태를 위한 큐(어떤 큐는 키보드 입력을 받는 프로세스를 넣는 큐,

  어떤 큐는 file io 를 기다리는 프로세스를 넣는 큐,

  process 끼리 공유하는 데이터에 대해, 일관성을 위해 한 번에 하나의 process 만 접근 가능한

  정책이 시행중일 때, 공유 데이터를 얻기 위해 기다리고 있는 프로세스를 넣는 큐 등)

 

위에 그림에서는 일반 큐처럼 그려놓았지만,

사실은 process priority 를 기준으로 하는 우선순위 큐임.

즉 우선순위가 높은 프로세스부터 큐에서 빠져나옴.

물론 이건 정책에 따라 달라짐.

일반 큐처럼 하는 것은 round robin 방식이지. 

 

os 는 (위에서 말한 것 처럼) PCB 를 통해 process 를 관리함.

각 process를 관리하기 위해 process 당 유지하는 정보가 PCB 에 저장됨.

PCB 에 저장하는 데이터는 다음과 같음

- os 가 관리상 사용하는 정보

 ㄴ process status(running, ready 등)

 ㄴ process ID

 ㄴ 스케줄링 info

 ㄴ priority : 큐에서 먼저 실행되어야하는 순서

- CPU 수행 관련 하드웨어 값

 ㄴ PC, CPU 의 레지스터들

- 메모리 위치 정보

 ㄴ code, data, stack 의 위치 정보. code data stack 이 메모리의 어디 위치해있는지.

- 파일 관련 정보

 ㄴ opne file sedcriptors ....등. 해당 process 가 사용중인 파일이 어떤건지.

 

 

Context Switching 을 하기 위해 기존 process A 의 정보들(pc, memory 위치 정보, 레지스터 값 등)을

os 가 관리하는 데이터 영역내, process A 를 위한 pcb 자리에 저장(백업)함.

그 후 process B 의 pcb 정보들을 cpu 와 메모리 등에 올리고 process B 를 실행

 

헷갈리기 쉬운 것 중 하나는,

사용자 process 가 실행중인 상태에서 하드웨어 interrupt(timer 가 아닌 interrupt) 나 system call 등에 의해

cpu 를 os 에게 넘기는 것은 context switching 이 아니라고 함.

왜냐면 os 가 일을 처리한 후 다시 방금까지 실행중이던 process에게 cpu 를 줄 것이기 때문에.

 

반대로 timer interrupt 나 io 요청 system call 을 하는 process 는 cpu 를 놓고

다른 process 에게 cpu 를 넘겨야 하기 때문에 context switching 이라고 부름.

 

 

 

아래는 내 생각.

첫번째 케이스에서 cpu 가 os 에게 넘어갔을 때 역시 process 의 정보들이 pcb 에 담기고

os 의 정보값들이 cpu 에 담기는 절차(context switching 이 일어날 때 교환되는 절차들)가

발생할 것 같은데... 어쨌든간에 cpu 를 사용하기 위해선 process 든 os 든 정보를 cpu 에

넣어야 할 것 아닌가? os 가 cpu 레지스터 사용 없이 실행될리 만무하고.

그럼 첫번째 케이스가 context switching 이라고 불리지 않는 이유는 

단지 논리적으로 process 가 다른 process 로 바뀌지 않기 때문인가?

실제로 벌어지는 일은 똑같은데?

-> 교수님이 이어서 해주신 설명에 해당 내용이 있음.

process 에서 os 로 cpu 가 넘어갈 때 물론 정보 백업 등이 일어나고 context switching 절차가

발생하기는 하지만, 그 overhead 가 일반 context switching 보다 적다고 함.

예를 들어 cpu 내의 cache memory 를 보자.

일반 context switching 이 일어나면 다른 process 로 바뀌기 위해 현재 cache memory 가

모두 flush 되어야 함. 이것은 상당한 overhead 라고 함

근데 (위에서 말하는 첫번째 케이스) os 로 CPU 가 넘어가는 경우는 cache memory flush 가

일어날 필요가 없기 때문에(다시 해당 process 에게 cpu 를 돌려주기 때문) 오버헤드가 적음

cache memory flush 절차를 생략하고 os 에게 cpu 가 넘어감. 그리고 다시 해당 procss 에게

cpu가 넘어가겠지. 이런 overhead 가 적기 때문에 context switching 이라고 부르지 않는가 봄.

 

 

 

 

위에서 설명한 큐를 나타내는 이미지.

여기서 말하는 큐는 os 의 메모리 주소 data 공간에 process 들을 상태별로 관리하기 위해

만들어둔 것이라고 설명하였음.

위에 이미지를 보면 상태별로, 그리고 device 별로 큐가 구현되어있는 것을 볼 수 있음.

어떤 process 는 ready 에 들어가 있고, 어떤 process 는 disk 에 들어가 있고...

여기서 큐에 들어가는 것은 process 를 관리하기 위해 만들어진 pcb 임.

pcb 를 큐에 넣어서 관리함.

(pcb는 context switching 을 통해 해당 process 를 되살릴 수 있는 정보들을 갖고 있지

따라서 pcb 를 큐에 넣고 저장한다는 것은, 해당 process 의 context 를 지닌 정보를

큐에 넣고 저장한다는 것과 일맥상통)