Process Management - Process

이영민·2023년 3월 18일

운영체제 프로세스

운영체제

목록 보기

1/11

1. Process Management

메모리에 로드된 사용자 프로그램 또는 메모리 관리와 운영체제 내부의 활동들을 위해 CPU를 사용하는 활동을 모두 프로세스라고 부른다.
프로그램은 명령어 리스트를 가진 실행 파일이며, 프로세스는 다음에 실행한 명령어인(program counter)와 관련 자원의 집합(스택, 데이터, 힙, 코드)을 가진 능동적인 존재이다.
프로세스중 저장장치에서 메모리로 적재된 프로그램은 메모리에 4가지로 구분된 텍스트 섹션, 힙, 데이터, 스택 영역에 적재된다.

A. Process State

new: 프로세스가 생성중이다.
ready: 프로세스가 처리기에 할당되기를 기다리는 중이다.
waiting: 프로세스가 어떤 사건(완료, 신호의 수신)을 기다린다.
running: 프로세스의 명령어가 실행된다.
terminated: 프로세스의 실행이 종료되었다.

B. Process Control Block

PCB 제어블록은 프로세스와 관련된 여러 정보를 가지고 있다.
다음에 실행될 명령어의 주소가 있는 프로그램 카운터, CPU레지스터들, CPU스케쥴링 정보, 메모리 관리 정보, 입출력 상태 정보 등등 프로세스마다 달라지는 상태를 저장하는 역할을 한다.

c. Thread

한 프로세스가 다수의 스레드를 가질 수 있게 하여 한 프로세스가 한번에 하나 이상의 일을 수행하도록 도와준다.

2. Process Scheduling

다중 프로그래밍의 목적은 CPU의 이용을 최대화 하기 위해서 항상 어던 프로세스가 실행되도록 하는 데 있다. 다중 프로그래밍 실현을 위해 시분할의 목적은 각 프로그램이 실행되는 동안 사용자가 상호 작용할 수 있도록 프로세스들 사이에서 CPU를 빈번히 교체하는 것이다. 이 목적을 달성하기 위해서 프로세스 스케쥴러는 CPU에서 실행 가능한 프로세스 중에서 하나의 프로세스를 선택한다.

a. Scheduling Queue

잡 큐: 시스템 안에 있는 모든 프로세스로 구성
준비완료 큐: 준비완료 상태에서 실행을 대기하는 프로세스이며, 준비완료 큐는 연결리스트(PCB가 다음 프로세스를 가지는 포인터 필드를 가진다.)의 형태로 저장되며, 준비완료 큐의 헤더는 리스트의 첫번째와 마지막 PCB를 가리키는 포인터를 포함한다.
장치 큐: 장치 사용을 대기중인 프로세스들의 리스트
아래의 그림은 준비완료 큐와 다양한 장치 큐를 나타낸 것이다.

아래는 프로세서 스케쥴링을 표현하는 큐잉 도표이다.

b. Scheduler

프로세스 큐에 있는 프로세스들의 선택은 스케쥴러에 의해 일어난다.
장기 스케쥴러: 디스크에 저장된 프로세스들중 어떤 것을 메모리에 적재할지 고르는 스케쥴러로, 메모리에 있는 프로세스의 수(다중프로그램의 수)를 제어한다. 장기 스케쥴러는 실행빈도수가 높지 않으므로 신중한 선택을 해야하며, 입출력 중심의 프로세스와 CPU 중심 프로세스의 적절한 균형을 맞추도록 프로세스를 선택해야한다.
단기 스케쥴러: CPU를 위해 프로세스를 선택하며 실행 빈도 수가 높다.

c. Context Switching

시스템에서 인터럽트 발생하고 그 처리가 끝났을 때, 프로세스의 상태를 다시 복구할 수 있도록 문맥을 저장할 필요가 있고 이런 문맥(CPU레지스터 값, 프로세스 상태, 메모리 관리 정보 등등)들은 PCB로 표현된다.
프로세스가 running 상태에서 인터럽트 혹은 waiting이 일어 날 때, CPU에서 running하는 프로세스는 바뀐다. 프로세스가 terminated되기 전까지 CPU에서 프로세스 교체가 빈번하므로 이러한 프로세스의 교체를 문맥 교환이라고 한다.
문맥 교환은 스케쥴러에 의해 인터럽트가 발생하고 문맥이 교환되는 일을 말하며 각 프로세스의 PCB를 불러와 문맥을 복구하며, 문맥 교환 시간 동안엔 시스템이 유용한 일을 하지 못하므로 이 시간은 순수한 오버 헤드이다.

3. Operation On Process

대부분 시스템 내의 프로세스들은 Concurrency하게 실행 가능하며, 반드시 동적으로 생성되고 제거 되어야 한다. 그러므로 운영체제는 프로세스 생성 및 종료를 위한 기법을 제공해야 한다.

A. Process Create

생성하는 프로세스는 부모 프로세스, 새로운 프로세스는 자식 프로세스라고 부른다. 이 새로운 프로세스들은 각각 다시 다른 프로세스들을 생성할 수 있으며, 이 결과 프로세스의 트리를 형성한다.
이러한 프로세스들은 리눅스에서 pid로 식별한다.
자식 프로세스는 요청 사항을 수행하기 위해 자원을 할당 받아야 하는데 3가지의 옵션이 있다.
1. 부모 프로세스와 모든 자원을 공유
2. 부모 프로세스가 가진 자원의 부분만 사용
3. 1. 부모 프로세스와 아무런 자원도 공유하지 않음.
자식 프로세스와 부모 프로세스가 실행 되는 2가지 옵션이 있다.
1. 자식과 부모 모두 Concurrency하게 실행 된다.
2. 자식 프로세스가 종료 될 때 까지 부모 프로세스는 Waiting 후 자식 프로세스 Terminated 후 부모 프로세스가 Terminated 된다.
주소 공간 관점에서 새로운 프로세스를 바라 볼 때 2가지 가능성이 존재 한다.
1. 부모 프로세스의 복제본
2. exec 함수를 통한 새로운 프로세스를 대기

B. Process Terminate

프로세스가 마지막 문장의 실행을 끝내고, exit() System call을 사용하여 운영체제에게 자신의 삭제 요청을 보내면 프로세스가 종료된다.
프로세스가 종료되면서 그 부모 프로세스에게 종료 상태 값을 반환하고 사용했던 자원들을 반납한다.
통상적으로 부모 프로세스는 자식 프로세스의 pid 를 알면 abort() System call을 이용하여 Terminated 가능하다. 부모는 다음과 같은 이유로 자식 프로세스를 강제로 Terminated 한다.
- 자식이 할당된 자원을 초과하여 사용할 때
- 자식에게 할당된 프로세스가 더 이상 필요 없을 때
- 부모가 exit해야하는데 시스템이 고아 프로세스를 허용하지 않는 경우
만약 부모 프로세스가 자식 프로세스의 Terminated를 wait하지 않는 경우 자식 프로세스는 고아 프로세스가 된다.
만약 부모 프로세스가 아직 어떤 요청을 수행 중 이어서 wait()함수를 아직 호출하지 못한 경우 자식 프로세스가 Terminated되어 exit()을 호출 했을 때, 자식 프로세스는 부모 프로세스가 wait() 함수를 호출할 때까지 기다려야 하므로 죽었지만 죽지 않고 살아있는 좀비 프로세스 가 된다.

4. Inter Process Communication

프로세스는 원래 서로의 데이터를 직접 주고받을 수 없다. (파워 포인트와 크롬은 데이터를 주고 받지 않는다.) - Independent Process
프로세스가 시스템에서 실행 중인 다른 프로세스들에게 영향을 주거나 받는다면 이는 협력 적인 프로세스이다. - Cooperate Process
프로세스 간 협력을 허락하는 이유: 정보 공유, 계산 가속화, 모듈성, 편의성
협력적 프로세스들은 데이터와 정보를 교환할 수 있는 프로세스 간 통신 기법을 필요로 한다. 그리고 통신 기법에는 공유 메모리와 메세지 전달의 두 모델이 있다.

A. Shared Memory System

공유 메모리를 사용하는 프로세스 간 통신에서는 통신하는 프로세스들이 공유 메모리 영역을 구축해야 한다.
공유 메모리 시스템을 구축할 때 System call 을 한 번 해야 한다.
통상적으로 공유 메모리 영역은 공유 메모리 세그먼트를 생성하는 프로세스의 주소 공간에 위치 한다.
공유 메모리 세그먼트를 이용하여 통신하고자 하는 다른 프로세스들은 이 세그먼트를 자신의 주소 공간에 추가 해야 한다.
일반적으로 운영체제는 프로세스 간 메모리 접근을 금지한다. 따라서 공유 메모리 사용을 원할 경우 서로 이 제약 조건을 제거 하는 것을 동의하는 것을 필요로 한다.
공유 메모리를 통한 통신의 제어는 운영체제가 아닌 프로세스가 가진다.
공유 메모리의 중요한 문제 중 하나는 둘이 동시에 동일한 위치에 쓰지 않도록 해야 한다는 것이다. → 동기화 문제가 이것을 해결
공유 메모리의 생산자 - 소비자 문제
- 생산자 - 소비자 문제란 어느 한 쪽은 생산만 하고 어느 한 쪽은 소비만 하는 것이다.
- 이 문제는 공유 메모리 영역에 둘 다 접근 가능한 버퍼를 생성 하여 한 쪽은 채우고 한쪽은 소비하는 방식을 통해 해결할 수 있다.
- 이 경우 공유 메모리의 동기화가 되어야 하고 동기화는 Critical Section(뮤텍스, 세마포어, 락)등의 방식으로 달성 될 수 있다.
- 버퍼 원형 큐 형식의 무한 버퍼를 통해 구현할 수 있다.