[스터디] 프로세스

프로세스의 상태

• 프로그램은 디스크에 저장된 정적인 데이터이고,
  프로세스는 메모리에 적재되어 실행 중인 동적인 상태이다.

• PCB는 운영체제가 프로세스를 관리하기 위해
  커널 영역에 생성하는 '상태 정보 저장소'이다.

• 프로그램 + 메모리 적재 + PCB 생성 = 프로세스
  (완료 시 PCB가 삭제, 프로세스 소멸)

활성 상태의 5단계

프로세스가 정상적으로 메모리에 머물며 실행 진행하는 상태이다.

1. 생성

• 프로그램이 메모리에 올라오고, 커널에 PCB가 막 생성된 시점

• 바로 실행되지 않는 이유는 CPU 자원은 한정되어 있고,
  이미 다른 프로세스들이 대기 중이므로 공평한 스케쥴링을 위해
  즉시 실행하지 않고 '준비 큐'로 이동시킨다.

2. 준비

• 메모리에는 올라와 있지만, CPU를 할당받지 못해 자신의 차례를 기다리는 상태

• 디스패치: CPU 스케줄러가 준비 큐에 있는 프로세스 중
  하나를 선택해 CPU 제어권을 넘겨주고 '실행' 상태로 만드는 과정

3. 실행

• CPU를 할당받아 실제 명령어를 처리하는 상태
  (동시에 실행 가능한 프로세스의 수는 CPU 코어 개수와 같다.)

• 타임 슬라이스와 인터럽트: 한 프로세스의 CPU 독점을 막기 위해
  제한 시간(타임 슬라이스)이 주어진다.
  하드웨어 클록이 시간을 재고, 시간이 만료되면 인터럽트를 발생시켜
  해당 프로세스를 강제로 '준비' 상태로 되돌린다.

4. 대기

• 실행 중이던 프로세스가 입출력 작업을 요청하여 작업이 완료될 때까지 멈춰 있는 상태

• 왜 대기 상태가 필요한가?: CPU 처리 속도에 비해 입출력 장치의 속도는
  수만 배 이상 느리다.
  입출력이 끝날 때까지 CPU가 해당 프로세스에 묶여 대기하면
  심각한 자원 낭비가 발생한다.
  따라서 요청을 한 프로세스는 대기 상태로 빼고,
  CPU는 즉시 준비 큐의 다른 프로세스를 실행하여 효율을 극대화한다.

• 왜 입출력 완료 후 '실행'이 아닌 '준비'로 가는가?: 입출력이 끝났다고 해서
  곧바로 현재 실행 중인 다른 프로세스에서 CPU를 빼앗아 넘겨주면,
  컨텍스트 스위칭 비용이 증가하고 스케줄링 로직이 복잡해진다.
  따라서 일단 '준비' 상태로 돌아가 순리대로 다시 차례를 기다리는 것이 논리적이다.

5. 완료

• 모든 작업이 끝난 상태이고, 사용하던 메모리, 열어 본 파일, CPU 자원을
  운영체제에 반납하고, PCB가 삭제된다.

• 코어 덤프: 오류 등으로 비정상 종료될 경우, 추후 디버깅을 위해
  프로세스가 죽기 직전의 메모리 상태를 그대로 파일로 저장하는 기능이다.

비활성 상태

메모리나 실행 흐름에서 일시적으로 벗어난 상태이다.
아래 두 상태의 차이는 '메모리 점유 여부'이다.

1. 휴식 상태

• 프로세스가 메모리에는 그대로 남아있지만 실행만 일시 정지된 상태

• 사용자가 명시적으로 중단 시그널을 보냈을 때 (예: Unix/Linux에서Ctrl + Z)

• 메모리에 남아있으므로 fg(포그라운드)나 bg(백그라운드) 명령어 등으로
  멈춘 지점부터 즉시 재시작이 가능하다.

2. 보류 상태

• 프로세스가 메모리에서 쫒겨나 디스크의 스왑 영역으로 이동한 상태

• 쫒겨난 이유는 물리적인 메모리 공간 부족하거나,
  너무 오랫동안 입출력 대기하고 있어 메모리를 차지하는 것
  자체가 비효율적이라고 운영체제가 판단했을 때 강제로 쫒아낸다.

• 보류 상태의 세분화

  • 보류 대기: '대기' 상태에서 메모리를 뺏김
    (스왑 영역에서 쫒겨난 채로 입출력 완료 기다림)

  • 보류 준비: 보류 대기 중 입출력이 완료되거나
    '준비' 상태에서 메모리를 뺏김,
    이 상태에서는 당장 실행할 준비가 되었지만
    메모리가 없어 대기 중이기에 다시 메모리만 할당받으면
    즉시 '준비' 상태로 복귀한다.

---

PCB(프로세스 제어 블록)의 필요성

• 운영체제가 프로세스를 관리하기 위해 커널 영역에 저장하는 상태 정보 묶음인
  PCB가 필요한 이유는 멀티태스킹 환경에서는 CPU가
  여러 프로세스를 번갈아 가며 실행한다.

  프로세스가 CPU를 넘겨줬다가 다시 할당받았을 때,
  처음부터 다시 시작하는 것이 아니라 멈춘 지점부터 이어서 실행하기 위해
  이전 상태를 기억할 장소가 필요하다.

• 프로세스가 생성될 때 고유한 PCB가 함께 커널에 만들어지고, 프로세스가
  종료되면 사용하던 자원가 함께 PCB도 폐기된다.

PCB의 구성 요소

• 포인터: 준비 큐나 대기 큐는 연결 리스트로 구현되므로
  다음 차례의 PCB를 가리키기 위해 필요하다.

• 프로그램 카운터(PC): 프로세스가 다음에 실행할 '명령어의 위치'를 가리킨다.
  CPU를 다시 얻었을 때 정확히 어느 코드부터 읽어야 할지 알아야 하기 때문이다.

• 레지스터 정보: 연산 중이던 CPU 내부 레지스터의 중관 결과값들이다.

• 상태 및 식별자: 현재 프로세스의 상태(준비, 실행 등)와 고유 번호(PID),
  부모/자식 관계(PPID, CPID)를 기록한다.

• 자원 정보: 현재 메모리 어디에 올라와 있는가?
  어떤 파일이나 입출력 장치(예: 사운드카드)를 쥐고 있는가를 기록한다.

문맥 교환

• CPU를 차지하던 프로세스를 내보내고, 새로운 프로세스를 실행 상태로 올리는 과정

• 현재 CPU의 상태(레지스터, PC 등)를 쫓겨나는 프로세스의 PCB에 저장

• 새로 들어올 프로세스의 PCB에서 과거 상태를 가져와 CPU에 덮어쓴다.

• 발생 조건은 할당된 시간을 다 썼을 때,
  입출력을 요청하여 대기 상태로 빠질 때 주로 발생한다.

타임 슬라이스(Time Slice)의 크기와 딜레마

• 문맥 교환은 당연히 기존 상태를 뒤엎고, 새 상태를 덮어쓰는데
  물리적인 시간이 소모된다.

• 타임 슬라이스가 너무 클 때: 한 프로세스가 CPU를 너무 오래 차지하므로, 다른 프로세스들의 대기 시간이 길어진다.
  (영상이 끊기거나 키보드 입력 반응이 느려짐)

• 타임 슬라이스가 너무 작을 때: 실제 프로그램을 실행하는 시간보다,
  문맥 교환 자체에 낭비하는 시간이 더 커진다.
  (컴퓨터 전체의 처리 성능과 효율이 급격히 저하됨)

• 결론: 문맥 교환에 버려지는 시간 비용을 고려하여,
  운영체제는 적절한 타임 슬라이스(유닉스 기준 10~200ms)를 설정해야 한다.