프로세스 = 실행 중인 프로그램
프로세스의 문맥 = 특정 시점을 놓고 봤을 때 어느 시점까지 진행을 했는지 파악하는 것
1. 프로그램 실행
2. 프로세스 A의 독자적인 주소 공간에 코드, 데이터, 스택 생성
3. 프로세스 A가 CPU 제어권을 받음
4. 프로그램 카운터라는 레지스터가 코드 특정 부분을 가리키고 있음
5. 그럼 매 순간 기계어를 읽어서 레지스터가 실행하고, 산술 연산 장치에서 작업을 하고, 결과를 레지스터에 저장하거나 외부의 메모리에 저장
6. 이걸 반복하다 어느 시점에 어느 시점에 왔는지 파악하는 게 프로세스의 문맥(context) -> 코드의 어느 부분까지 진행했는가, 스택에 어느 데이터를 저장하고 쌓아놓고 있는가, 변수의 값은 얼마인가, 레지스터에 어떤 값이 있고 어떤 연산까지 진행했는가, 등등의 모든 요소를 알고 있을 때
문맥 1. CPU와 관련된 하드웨어의 문맥.
프로세스 -> CPU를 잡아서 매 순간 인스트럭션(기계어)을 실행하는 것. 주로 레지스터가 어떤 값을 가지고 있는지, 등등
문맥 2. 메모리와 관련된 프로세스의 주소 공간
코드 데이터 스택에 어떤 값이 저장되어 있는가. 이를 통해 프로세스의 문맥을 나타냄
문맥 3. 운영체제의 역할 -> 운영 중인 프로세스 관리. 프로세스가 생길 때마다 프로세스를 관리하기 위해 자신의 데이터 영역에 PCB라는 자료구조를 생성.
*커널 스택(Kernel stack): 사용자 프로그램이 자신이 처리할 수 없는 일을 대신 부탁할 때, 시스템 콜. 그럼 프로그램 카운터가 사용자 프로그램이 아니라 커널의 코드를 가리켜서 실행. 커널 코드는 어떤 프로그램이든 요청을 통해 실행할 수 있음. 커널은 그럼 누구의 부탁을 받아 실행하는지 저장하기 위해 스택에 프로세스별로 별도로 저장.
이런 문맥이 왜 필요한가?
현대의 컴퓨터 시스템은 타임 셰어링, 멀티 태스킹을 통해 프로세스들이 번갈아 사용됨. 때문에 프로세스의 현재 문맥을 알고 있지 않으면 다음번에 CPU를 잡았을 때 앞부분부터 다시 시작해야 하는 등의 문제 발생.
CPU가 하나인 환경. CPU를 잡고 있는 프로세스는 매 순간 하나.
Ready: 당장 필요한 부분(디스크의 파일 등등)이 모두 준비되어 바로 CPU를 사용할 수 있는 상태.
ready 상태에 있는 프로그램들이 번갈아가면서 CPU를 사용. 최소한의 메모리는 가지고 있어야 함
Running: CPU를 잡고 인스트럭션을 수행중인 상태
Blocked(wait, sleep): CPU를 줘도 I/O 기기(ex. 디스크)에서 데이터를 가져와야 하는 등의 문제 때문에 당장 작업을 처리할 수 없는 상태. 메모리 공간을 효율적으로 사용하기 위해 프로그램 전체를 메모리에 올려놓고 사용하지 않음. 이렇게 메모리가 아닌 디스크에 올라가 있는 프로세스 등등.
Terminated: 수행이 끝난 프로세스를 정리하는 상태
CPU는 굉장히 빠르고 공유하는 자원
Queue: 하나의 프로세스가 CPU에서 러닝을 하다가 타이머가 들어오면 CPU를 뺏기고 맨 뒤 순서로
CPU에서 프로세스가 작업을 하다가 I/O 장치에서 필요한 것들을 가져와야하면 BLOCKED 상태로 변하고 필요한 정보를 가지러 감. I/O 작업이 종료되면 커널에서 blocked 상태의 프로세스가 ready 상태가 될 수 있는 자격을 줌(ready queue에 줄을 섬).
* 공유 데이터: 특정 프로세스가 공유데이터에공유 데이터에 접근하고 있으면 다른 프로세스가 공유 데이터에 접근하는 걸 막음. 이렇게 다른 프로세스가 접근한 공유 데이터에 접근하려면 줄을 서고 blocked 상태가 됨(Blocked queue에 위치함)
이러한 큐들은 커널의 데이터 영역에 자료구조로 저장되어 있음
프로세스 하나 당 PCB를 하나씩 가짐
(1) 프로세스 상태, ID, CPU를 주기 위한 우선순위. 큐에서 CPU를 주는 건 라운드 로빈이 아니고 스케쥴링과 우선순위에 따라서
(2) 프로세스의 문맥을 표시하기 위한 정보. CPU에 어떤 레지스터 값을 주어서 실행중이었는가
(3) 메모리 관련 문맥. 코드, 스택이 메모리의 어디에 위치해있는가
(4) 파일 관련
CPU는 매우 빠르기 때문에 줬다가 뺏겼다가를 반복. 때문에 다시 CPU를 가져왔을 때 작업을 이어갈 문맥(context)이 필요함.
문맥 교환: CPU가 사용자 프로세스에서 다른 사용자 프로세스로 넘어가는 과정
Process A가 실행 중 -> 프로그램 카운터(PC)가 프로세스 A의 PCB를 가리키고 있음. 그런데 CPU를 빼앗기게 되면 다음에 시작할 때, 원래 작업하던 위치부터 다시 작업을 시작하기 위해 레지스터에 저장돼있던 값과 PC가 가리키는 위치를 프로세스의 PCB에 저장. 커널에 A의 PCB를 저장하기 위한 공간이 data 영역에 PCB들 저장
반대로 CPU를 얻은 프로세스들은 저장되어있던 PCB를 이용해서 작업을 복원하고 CPU로 작업을 재개.
Context switch: CPU 제어권이 사용자 프로그램에서 다른 사용자 프로그램으로 넘어감
System call 또는 Interrupt: CPU 제어권이 운영체제에게 넘어감. 이것만으로는 문맥 교환이 아님.
* timer interrupt -> cpu를 다른 프로그램에게 넘기기 위한 의도.
(1)의 과정도 약간의 save는 필요함. 하지만 아예 프로세스를 변경하는 작업보다는 오버헤드가 적음.
프로세스를 변경하려면 캐시 메모리를 아예 삭제해야 함. 여기서 오버헤드 발생. 하지만 (1)의 상황에서는 그렇게까지는 하지 않음.
- Device queue: 각 I/0장치마다 서비스를 기다리는 큐
- Job queue: ready queue와 device queue 모두를 포함
queue에는 PCB를 줄 세움. 그래서 PCB가 포인터로 주소를 가지고 있음.
CPU로 작업을 하다가 오래 걸리는 작업(I/O)을 하게 되면 IO 큐에서 기다리다가 그 작업이 끝나면 다시 CPU를 사용할 수 있는 ready queue에서 대기하다가 다시 CPU를 얻어 작업. 또는 자식 프로세스를 만들고 그 자식 프로세스가 작업하는 동안 잠시 쉬었다가 나중에 다시 작업하기도 함.
자원별로 무슨 일을 할지 정하는 것.
Long-term scheduler: 메모리를 어떤 프로세스에게 줄지 결정하는 문제.
프로세스는 메모리에 올라가야만 ready 상태가 될 수 있음. Long-term 스케쥴러가 new 된 프로세스에게 메모리에 줄지 말지 결정.
degree of Multiprogramming: 메모리에 올라가는 프로세스의 수. 메모리에 너무 많은 프로그램이 동시에 올라가도 CPU의 성능이 좋지 않고, 그렇다고 너무 조금 올라가도 성능이 좋지 않음.
Short-term scheduler: 굉장히 빠르고 잦은 스케줄.
Medium-term scheduler: 지금의 시스템 -> 프로세스가 시작되면 일단 메모리는 줌. 하지만 이렇게 하면 메모리에 너무 많은 프로그램이 동시에 올라가기 때문에 중기 스케쥴러를 두고 사용. 스와퍼가 메모리에서 프로세스를 선별해서 degree of multiprogramming을 제어함.
-> Suspended(stopped): 중기 스케쥴러 등에 의해 프로세스가 통째로 중지된 상태. 메모리에서 완전히 쫓겨나서 디스크로 swap out 됨.
Blocked: 자신의 요청에 의해
Suspended: 외부에 의해 강제로. 사용자가 강제로 프로세스를 정지시킬 수도 있음. 이것 역시 외부 요인.
- user mode Running : 프로세스가 CPU를 가지면서 자신의 코드를 실행
- monitoring Running: 시스템 콜을 통해 자신이 할 수 없는 작업을 운영체제에게 요청하고 운영체제의 코드가 실행되는 것 역시 사용자의 프로세스가 '커널 모드'에서 running 중이라고 부름. 운영체제가 running 하고 있다고 하지 않음.
'Information Technology > OS' 카테고리의 다른 글
[운영체제] Process Management(1) (0) | 2020.01.26 |
---|---|
[운영체제] Process(2) (0) | 2020.01.24 |
[운영체제] System Structure & Program Execution(2) (0) | 2020.01.15 |
[운영체제] System Structure & Program Execution(1) (0) | 2020.01.13 |
[운영체제] Introduction to Operating Systems (0) | 2020.01.10 |