운영체제 교안 : Chap 04 Process

CHAP 04 Process

 

📌 프로세스 개념

* Process란? 메인 메모리에 로드되어 실행중인 프로그램

 

[프로세스 요소 5가지]

💡코드 섹션 (텍스트 섹션) : 기계어 코드, 실행 코드

💡데이터 섹션 : 전역 변수 (프로그램 실행 중 필요한 data)

💡스택 : 함수를 호출할 때 임시 데이터 저장장소, 로컬 변수 

💡프로그램 카운터

  : 마이크로 프로세서에 있는 레지스터, 다음 실행될 명령어 주소를 가지고있어 실행할 기계어 코드의 위치 지정

💡힙: 실행중에 메모리 요청하면 힙 메모리를 할당해줌

 

[프로세스 메모리 배치] 

📌 프로세스 상태

: 프로세스는 실행되며 상태가 변한다. 상태는 그 프로세스의 현재 활동에 따라 정의된다. 프로세스는 다음상태 중 하나에 있게 된다.

1. new : 프로세스 생성 중

2. running : 명령어들 실행 중, CPU를 가지고 있는 상태

3. wating : 프로세스가 어떤 이벤트 (입출력 완료 or 신호 수신 같은)가 일어나길 기다림

4. ready : . CPU가 주어지기를 기다리는 상태, 프로세서가 처리기에 할당되기를 기다린다

5. terminated : 프로세스의 실행이 종료되었다.

 

💡ready vs wating 차이점

- ready : 다 준비 됨. CPU 하나만 있으면 됨 

- waiting : CPU외에도 준비 안됨. 입출력같은 행위 기다리고 있음

 

[프로세스 상태 다이어그램]

: 각 화살표 및 상태 암기

💡scheduler dispatch (ready > running)

: 제어권을 주는 것. CPU 가짐

 

📌 프로세스 제어 블록 (PCB)

:  운영체제가 프로세스를 제어하기 위해 정보를 저장해 놓는 곳으로, 프로세스의 상태 정보를 저장하는 자료구조

• 각 프로세스는 운영체제에서 프로세스 제어블록에 의해 표현된다.
• 프로세스 제어 블록은 특정 프로세스와 연관된 여러 정보를 수록한다. (프로그램 카운터, 상태 등)
• PCB 구성 요소 : 프로세스 상태, 프로그램 카운터, CPU 레지스터, CPU Scheduling 정보, 메모리 관리 정보, Accounting 정보, 입출력 상태 정보 

💡PCB에 스택이 포함될까?

: X, 메모리 자체를 포함하지는 않고 메모리에 대한 정보를 가진다!!

 

📌 Context Switch  (제어권 줄 때 발생, 상황 정보가 바뀐다고해서 컨텍스트 스위치)

: p0가 타임아웃 인터럽트가 걸렸다고 가정했을 때, CPU 제어권이 운영체제에 넘어가서, 이 제어권을 P1에게 주려고 함. p0의 작업은 저장하고, 후에 실행할 때 다시 복구해야함. 이 과정을 컨텍스트 스위치라고 한다. 

> 이전 작업 저장, 새로 시작할 작업 복원.

• 인터럽트는 운영체제가 cpu코어를 현재 작업에서 뺏어 커널 루틴을 실행할 수 있게 함
• 인터럽트 발생 시, 시스템은 인터럽트 처리가 끝난 후 문맥을 복구하도록 현재 실행중이 프로세스를 저장 (이는 프로세스를 중단했다가 재개하는 작업이다.)
• 문맥은 PCB에 표현된다. 문맥은 CPU의 레지스터 값, 프로세스 상태, 메모리 관련 정보 등을 포함한다.
• CPU 코어를 다른 프로세스로 교환하려면 이전 프로세스 상태 보관, 새로운 프로세스 상태 복구 작업이 필요하다. >> 이 작업이 컨텍스트 스위치이다.
• 문맥교환이 진행될 동안 시스템은 아무런 일을 못하기 때문에, 문맥교환 시간은 순수한 오버헤드이다. (속도는 기계마다 다름)
• 문맥 교환 시간은 하드웨어 지원에 크게 좌우됨

 

📌 프로세스 스케줄링

- 다중 프로그래밍의 목적은 CPU의 이용을 최대화 하기 위해, 항상 어떤 프로세스가 실행되도록 하는 데 있다. 

  > CPU 놀지마!

- 프로세스 스케줄러 : 코어에서 실행 가능한 여러 프로세스 중 하나의 프로세스를 선택 (시분할을 통해 실행하는 프로세스를 주기적으로 교체한다. - 병행성)

- 다중 프로그래밍 정도 : 현재 메모리에 있는 프로세스 수

- I/O bound process : 계산보다 I/O 작업에 더 많은 시간을 소비하는 프로세스  (ex. 하드디스크 포맷 작업)

• CPU bound process : 계산에 더 많은 시간을 소비하여 I/O 작업에 요청을 자주 생성하지 않는 프로세스 (ex. 파이 값 구하기 프로그램)

❓A,B,C 모두 CPU-bound process라면, 어떤 queue가 많이 찰까? 

= Ready Queue. I/O queue에 요청을 생성하지 않기 때문

 

📌 CPU 스케줄링

- CPU 스케줄러(short term 스케줄러)의 역할은 ready 큐에 있는 프로세스 중 선택된 프로세스에 cpu 할당하는 것이다.

> CPU 스케줄러는 CPU를 할당하기 위한 새 프로세스를 자주 선택해야한다.

- job 스케줄러(long term 스케줄러)의 역할은 어떤 프로세스를 ready 큐에 넣을 지 할당하는 놈이다.

> 멀티 프로그래밍을 제어하는 컨트롤러로 job 단위로 분리해서 스케줄을 짠다. (드물게, 느리게 선택)

- Mid-term scheduler : Long-term + Short-term

💡Job Queue (Long-term scheduler): 모든 프로세스를 포함하는 큐

💡Ready Queue(CPU Scheduler(Short-term scheduler)) : ready 상태의 프로세스를 포함하는 큐

💡Device queues : I/O를 기다리는 큐

 

 📌 Scheduling Queues 

: 프로세스가 시스템에 들어오면 job queue에 놓여진다. 이 큐는 시스템 안의 모든 프로세스들로 구성된다. 주 메모리에 존재하며 process state가 ready인 프로세스들은 ready queue라 불리는 리스트 상에 유지된다. 이 큐는 보통 연결 리스트로 저장된다. ready queue의 헤더는 리스트의 첫 번째와 마지막 PCB를 가리키는 포인터를 포함한다. 각 PCB는 ready queue에 있는 다음 프로세스를 가리키는 포인터 필드를 가진다. job queue와 ready queue말고도 여러 큐가 시스템에 존재한다. 프로세스가 디스크 같은 입출력 장치에 요청을 했다 가정하자. 만약 이 디스크가 다른 프로세스들의 요청으로 바쁘다면, 프로세스는 디스크를 기다려야 할 수도 있다. 특정 입출력 장치를 대기하는 프로세스들의 리스트를 device queue라고 한다. 각 장치는 위 그림처럼 자신의 device queue를 가진다.

 

📌 queueing diagram

 

: 프로세스 스케줄링의 공통적인 표현 방식은 아래 그림 2와 같은 queueing diagram이다. 각 사각형은 하나의 queue를 나타낸다. 두 가지 타입의 큐(ready queue, device queues)가 존재한다. 원은 queue를 서비스하는 자원이며, 화살표는 시스템에서 프로세스들의 흐름을 표현한다. 

 

 

새로운 프로세스는 처음에 ready queue에 놓인다. 프로세스는 CPU를 할당받을 때(dispatch)까지 ready queue에서 대기한다. 프로세스에 CPU가 할당되어 실행되면 아래 사건들 중 하나가 발생할 수 있다.

 

• 프로세스가 I/O(입출력)을 요청하여 I/O queue에 넣어질 수 있다.
• 프로세스가 child process를 생성하고 그 프로세스의 종료를 기다릴 수 있다.
• 프로세스가 interrupt의 결과에 따라 강제로 CPU로부터 제거되어 ready queue에 다시 놓일 수 있다.

 

프로세스는 결국 waiting state에서 ready state로 전환되고 다시 ready queue에 넣어진다. 프로세스는 종료될 때까지 이 주기를 계속하며, 종료되면 모든 queue에서 삭제되고 프로세스의 PCB와 자원을 반납(deallocate)한다.

 

📌 프로세스에 대한 연산

[프로세스 생성]

• 실행되는 동안 프로세스는 여러 개의 새로운 프로세스들을 생성할 수 있다.
• 생성하는 프로세스를 부모 프로세스, 새로운 프로세스를 자식 프로세스라고 부른다.
• 새로운 프로세스는 fork() 시스템 콜로 생성 in UNIX
• exec() 시스템 콜로 자신의 메모리 공간을 새로운 프로그램을 교체하여 프로그램 실행 시작 in UNIX
• 새로운 프로세스들은 각각 다시 다른 프로세스 생성이 가능하며, 그 결과 프로세스 트리를 형성한다.
• 대부분의 현대 운영체제들은 유일한 프로세스 식별자(pid)를 사용하여 프로세스를 구분한다.
• pid는 시스템의 각 프로세스에 고유한 값을 가지도록 할당된다.

💡 부모 프로세스와 자식 프로세스의 자식 공유 옵션

   1) 부모 자식간 모든 자원 공유(기본 값) 
   2) 자식이 부모의 일부 자원만 공유
   3) 부모 자식간 어떠한 자원도 공유하지 않음

 

💡 프로세스 실행 옵션

   1) 부모 자식 프로세스 동시 실행(멀티 태스킹)
   2) 부모가 자식의 종료까지 기다림 (wait)

 

[fork() 시스템 콜을 사용하여 별도의 프로세스 생성 - 코드] 

>> 새로만들어진 프로세스의 pid = 0, return 0일때 child process임을 알수 있다.

 

[프로세스 종료]

: 프로세서가 마지막 문장의 실행을 끝내고, exit 시스템 콜을 사용하여 운영체제에 자신의 삭제를 요청하면 종료한다. 이 시점에서 프로세스는 자신을 기다리고 있는 부모 프로세스에(wait 시스템 콜을 통해) 상태 값을 반환할 수 있다. 반환 시에는 물리 메모리와, 가상메모리, 열린 파일, 입출력 버퍼를 포함한 모든 자원이 할당 해제되고 운영체제로 반납된다.

 

💡부모는 다음의 경우 abort() 시스템 콜을 이용하여 자식 중 하나의 실행을 종료할 수 있다.

   1) 자식이 할당된 자원을 초과했을 때
   2) 자식에게 할당된 업무가 더 이상 필요 없을 때
   3) 부모가 exit하는데 운영체제는 부모가 exit한 후에 자식이 실행을 계속하는 것을 허용하지 않는 경우

 

💡 몇몇 시스템에서는 부모 프로세스 종료 후 자식 프로세스가 존재할 수 없다.

• cascading(연쇄) 종료: 프로세스가 정상적/비정상적이든 종료되면 비롯된 모든 자식프로세스도 종료되야함
• 프로세스 종료 시 사용하던 자원은 운영체제가 되찾아감
• 좀비 프로세스: 자식 프로세스는 종료되었지만 부모 프로세스가 wait을 호출하지 않았기 때문에 호출 시까지 종료 상태가 프로세스 테이블에 남아있게 된 상태를 말함
• 고아 프로세스: 브모 프로세스가 wait() 호출 대신 종료를 한 상태 > 영원히 자식은 테이블에 종료상태로 남아있어야함

 

프로세스간 협업

: 정보 & 시그널 주고 받아 협력

 

💡특징

1. 다른 프로세스에 영향을 미치거나 영향을 받을 수 있다.
2. 정보 공유
3. 계산 속도가 빨라짐
4. 모듈화
5. 편리함

• 2개 이상의 프로세스가 data share, in out 함께 접근할 시 , 같은 데이터 동시에 접근하면 문제 발생함 ! (레이스 컨디션 이라고 함, 경쟁상황 의미)

📌 프로세스 간 통신 (IPC: Inter process Communication)

: 운영체제 내에서 실행되는 병행 프로세스들은 독립적이거나 협력적인 프로세스들 일 수 있다. 시스템에서 실행 중인 다른 프로세스들과 데이터를 공유하지 않는 프로세스는 독립적이다. 프로세스가 시스템에서 실행 중인 다른 프로세스들에게 영향을 주거나 받는다면 협력적인 프로세스이다.

 

💡프로세스 협력을 허용하는 환경을 제공하는 이유

- 정보 공유
- 계산 가속화 (복수 개의 처리 코어를 가진 경우에만 가능함을 유의!)
- 모듈성

 

💡 협력적인 프로세스들은 저로 데이터를 교환할 수 있는 통신(IPC) 기법이 필요하다.

• 공유 메모리(shared memory): 협력 프로세스들에 의해 공유 메모리 영역 구축된다. 그 영역의 데이터를 읽고 쓰고 함으로써 정보를 교환할 수 있다.
• 메시지 전달(msg passing) : 협력 프로세스들 사이에 교환(send-receive)되는 메시지를 통하여 정보교환이 이루어진다. 충돌을 회피할 필요가 없기 때문에 적은 양의 데이터 교환에 유리

💡producer-consumer problem in 협력하는 프로세스 간

: 협력 프로세스를 위한 패러다임인 생산자 프로세스는 소비자 프로세스에 의해 소비되는 정보를 생산

• 무한정 버퍼인 경우(unbounded-buffer) : 버퍼의 사이즈에 제한이 없기 때문에 계속해서 버퍼에 채울 수 있다.
• 한정된 버퍼인 경우(bounded-buffer) : 고정된 사이즈의 버퍼인 경우 버퍼가 다 찼다면 더이상 생산자는 자리가 나기 전까지 더이상 생산하면 안되고, 버퍼가 텅 비어있다면 소비자는 소비할 게 없음을 알려야한다. (연동 필요)
• 프로듀서가 enter() 호출
• 소비자가 remove() 호출

📌 공유 메모리(shared memory) 시스템에서의 프로세스 간 통신

• 공유 메모리를 사용하는 프로세스 간 통신엔 프로세스들이 공유하는 메모리 영역을 구축해야한다.
• 통신은 유저 프로세스에 의해 결정되며 운영체제 소관이 아님!
• 동일한 메모리에 동시에 wirte 작업 시 문제가 발생 >> 한 프로세스만 쓰기 가능하도록 동기화 해야함

]📌 메시지 전달 (msg passing) 시스템에서의 프로세스 간 통신

• 메시지 전달 방식은 동일한 주소공간을 공유하지 않고도 프로세스들이 통신하고, 그들의 동작을 동기화 할 수 있도록 허용하는 기법을 제공한다. 메시지 전달 방식은 통신하는 프로세스들이 네트워크에 의해 연결된 다른 컴퓨터들에 존재할 수 있는 분산 환경에서 특히 유용하다.

* 두 가지 주연산

1. send(message)
2. receive(message)

: 프로세스가 보낸 메시지는 고정길이(시스템 구현 easy, 프로그래밍 작업 difficult)일 수도 있고, 가변 길이(시스템 구현 difficult, 프로그래밍 작업 easy)일 수도 있다.

 

💡만약 프로세스 P와 Q가 통신을 원한다면, 통신연결(link)가 만들어져야한다. 하나의 링크와 send()/receive() 연산을 논리적으로 구현하는 다수의 방법

1. 직접 통신 or 간접통신
2. 동기식 or 비동기식 통신
3. 자동 or 명시적 버퍼링

📌 직접 통신

• 통신시 송수신자 이름이 명확하다.
• 장점: 프로세스가 하나 늘어날 때마다 필요한 링크 수가 늘어서 효율은 떨어지나, 연결만 되면 확장성 good
• 단점: 프로세스 이름 특정해야하기 때문에 이름 변경 시 연관된 모든 다른 프로세스 부분 검사 필요(모듈성 저하)
• send(p, message) - 프로세스 p에 메시지 전송
• receive(Q, messsage) - 프로세스 Q로부터 메시지 수진

* 직접 통신 연결 특성

1. 통신을 원하는 각 프로세스 쌍들 사이에 연결이 자동으로 구축된다.
2. 연결은 정확히 두 프로세스 사이에만 연관된다.
3. 통신하는 프로세스들의 각 쌍 사이에는 정확하게 하나의 연결이 존재해야한다.
4. 송신자만 수신자 이름을 지명하는 것도 가능함(주소지정 비대칭)

📌 간접 통신

• 메시지들이 메일박스 또는 포트로 송신되고 그것으로부터 수신된다.
• 메일박스는 고유의 id를 가진다. 
• 다수의 상이한 메일박스를 통해 다른 프로세스들과 통신할 수 있다.
• 두 프로세스들이 공유 메일박스를 가질 때만 이들 프로세스가 통신할 수 있다.
• send(A, message) : 메시지를 메일박스 A로 송신
• revecive(A, message) : 메시지를 메일박스 A로부터 수신

* 간접 통신 연결 특성

1. 한쌍의 프로세스들 사이의 연결은 이들 프로세스가 공유 메일박스를 가질 때만 구축된다.
2. 연결은 두 개 이상의 프로세스들과 연관될 수 있다.
3. 통신하는 각 프로세스 사이에는 다수의 서로 다른 연결이 존재할 수 있고, 각 연결은 하나의 메일박스에 대응

* 간접통신 문제 발생 예시

: 메일 박스 A를 프로세스 p1,p2,p3가 공유할 때 프로세스 p1 메시지를 A에 송신하고(send(p1, A)) p2,p3는 각각 receive()를 실행한다. 그렇다면 p2,p3 중 누가 이 메시지를 수신하는 가?

 

>> 해결책

• 하나의 링크는 최대 2개의 프로세스와 연관되도록 허용
• 한순간의 최대로 하나의 프로세스가 receive() 연산을 실행하도록 허용
• 어느 프로세스가 메시지를 수신할 것인지 시스템이 임의로 선택하도록 한다. 시스템은 송신자에게 수신자를 알려줘야한다.

* OS는 한 프로세스에 다음을 허용하는 (연산)기법 제공

1. 새로운 메일 박스 생성
2. 메일박스를 통해 송수신
3. 메일박스 삭제

📌 동기화 (Synchronization)

: 메시지 전달은 blocking(봉쇄형)이거나, no-blocking(비봉쇄형) 방식 이다. 각각 동기식/비동기식으로도 부름

• blocking send(synchronous) : 송신하는 프로세스는 메시지가 수신 프로세스 또는 메일박스에 의해 수신될 때까지 봉쇄된다.
• blocking receive(asynchronous) : 메시지가 이용 가능할 때까지 수신 프로세스가 봉쇄된다.
• non-blocking send : 송신하는 프로세스가 메시지를 보내고 작업을 재시작한다. (다음 메시지 보내기 > 받았든 말든 상관 안하는 싹바가지)
• non-blocking receive : 송신하는 프로세스가 유효한 메시지 또는 널을 받는다.

>> send와 receive 각 다른 조합도 가능하다. 만일 send와 receive가 모두 봉쇄형일 때, 송수신자간 랑데부(약속)를 가지게 된다.

 

📌 소켓

: 소켓은 통신의 극점을 뜻한다. 두 프로세스가 네트워크 상에서 통신을 하려면 양 프로세스마다 총 두 개의 소켓이 필요해진다.

• 소켓은 IP 주소 + 포트번호 두 가지를 접합한 형식이다.
• 일반적으로 소켓은 클라이언트-서버 구조를 사용한다.
• 서버는 지정된 포트에 클라이언트 요청 메시지가 도착하기를 기다리게 된다. 요청이 수신되면 서버는 클라이언트 소켓으로부터 요청을 수락함으로써 연결이 완성된다.
• 정보 받는 쪽/보내는 쪽 둘다 소켓 생성 가능 (급한쪽이 먼저 만드는 듯)

>> 서로 다른 시스템의 두 프로세스가 네트워크를 통해 메시지 전달 가능

 

 

📌 UDP & TCP

* UDP란?

: 속도 빠름, 인터넷으로 음성 채팅

* TCP란?

: 보내는 과정에서 TCP 이용 시, 보낸 문서와 받는 순서가 그대로 유지. 에러 처리도 해줌. (전화 라인 처럼, 서로 연결해둔 것처럼 데이터 전송됨. 대부분의 서비스가 TCP임)

 

📌 원격 프로시저 호출 (RPCs) >> 시스템 연결되어있어 원격 호출 가능!!

: 소켓보다 수준 높은 통신이 가능하다. 네트워크에 연결된 두 시스템 사이의 통신에 사용하기 위하여 프로시저 호출 기법을 추상화 하는 방법으로 설계되었다. 프로세스들이 서로 다른 시스템 위에서 돌아가기 때문에 메시지 기반 통신을 해야한다.

 

* 스텁 : 서버의 실제 절차에 대한 클라이언트 측 프록시(중계서버)이다.

 

📌 Remote Method Invocation (RMI)

: 분산되어 존재하는 객체 간의 메시지 전송(메소드를 호출하는 것 포함)을 가능하게 하는 프로토콜.

• RPC와 유사한 Java 매커니즘
• RMI를 사용하면 한 컴퓨터의 Java 프로그램이 원격 개체에서 메서드를 호출할 수 있음

+ 📌 파이프

[ 파이프 구현 시 고려할 4가지 문제 ]

1) 파이프가 단뱡항 통신인가 양방향 통신인가?

2) 양방향 통신이 허용된다면 반이중 방식인가, 전이중 방식인가?

1. 반이중 방식 : 한번에 한방향 전송만 (ex.무전기)
2. 전이중 방식 : 동시에 양방향 데이터 전송 가능 (ex.전화통화)

3) 통신하는 두 프로세스 간 부모 - 자식 같은 특정 관계가 존재하는가?

4) 파이프끼리 네트워크를 통해 통신이 가능한가? 아니면 동일 기계 안 존재하는 두 프로세스끼리만 통신 가능한가?

 

일반 파이프 (ordinary pipe)

: 한쪽으로만 데이터를 전송할 수 있으며, 오직 단방향 통신만 가능하다. 만일 양방향 통신이 필요하다면, 각각 다른 방향의 총 2개의 파이프가 필요 >> 일반 파이프는 파이프를 생성한 프로세스 이외에는 접근 불가능하기 때문에 주로 부모 프로세스가 파이프를 생성하고 fork()로 생성한 자식 프로세스와 통신하기 위해 사용한다.

 

지명 파이프 (named pipe)

: 일반 파이프는 한쌍의 프로세스가 통신할 수 있는 방법을 제공한다. 그러나 일반 파이프는 오로지 프로세스들이 서로 통신하는 동안에만 존재한다. 지명 파이프는 양방향 통신이 가능하며, 부모-자식 관계가 아니어도 사용 가능하다. 여러 프로세스 들이 이를 사용하여 통신이 가능하다. 추가로 통신 프로세스가 종료되더라도 지명 파이프는 계속 존재한다. > 유닉스, 윈도우 둘다 지명 파이프 제공