프로세스란?

프로세스의 정의

• 수행 중인 프로그램
• 컴퓨터 상에 수행 중인 프로그램의 인스턴스
• 처리기에 할당되어 수행될 수 있는 개체(entity)
• 명령들의 순차 수행, 현재 상태, 연계된 시스템 자원들의 집합 등에 의해 특징지어지는 활성화 단위

프로세스의 필수적인 요소

프로세스는 수많은 요소들로 구성된 개체로도 생각할 수 있다. 필수적인 요소는

• 프로그램 코드
  - 동일 프로그램을 수행하는 서로 다른 프로세스들이 공유할 수 있는 부분
• 데이터의 집합
  - 해당 프로그램 코드와 연계된 데이터의 집합
  가 있다.

프로세스의 여러 요소들

처리기가 프로그램 코드를 수행한다고 가정하면 수행중인 개체를 프로세스라고 하며, 프로그램의 수행 중 특정 시점에서 다음으로 식별될 수 있다.
아래 목록들의 정보는 프로세스 제어 블록에 저장되며, 운영체제에 의해 생성되어 관리된다.

• 식별자
  - 프로세스를 구분시켜주는 식별자
• 상태
  - 수행(Running) 상태
• 우선순위
  - 다른 프로세스들에 대해 상대적인 우선순위 수준
• 프로그램 카운터
  - 프로그램에서 다음에 수행될 명령어의 주소
• 메모리 포인터
  - 프로그램과 연계된 프로그램 코드 및 데이터, 다른 프로세스들과 함께 공유되는 메모리 블록들에 대한 포인터 등
• 문맥 데이터(context data)
  - 프로세스가 수행중일 때 처리기의 레지스터에 존재하는 데이터
• 입출력 상태 정보
  - 미해결 입출력 요청, 프로세스에 할당된 입출력 장치, 파일 리스트 등
• 어카운팅 정보
  - 사용된 처리기 시간 및 클록시간, 시간 제한, 계정 번호 등

이러한 프로세스 제어 블록은 수행 프로세스를 인터럽트한 후 나중에 그 인터럽트가 발생되지 않은 것처럼 프로세스 수행을 재개할 수 있도록 충분한 정보를 유지하여 다수의 프로세스를 지원하고 멀티프로세싱을 제공할 수 있게 해주는 주요 도구이다.
따라서 프로세스는 프로그램 코드 및 관련된 데이터, 그리고 프로세스 제어 블록으로 구성되어 수행된다.

프로세스 상태

프로그램을 수행하기 위해 프로그램에 대한 프로세스/태스크가 실행되고 처리기는 프로그램 카운터 레지스터 값에 의해 결정된 순서에 따라 명령어들을 수행한다.

개별 프로세스 행위의 특성은 프로세스를 위해 수행되는 일련의 명령어 리스트로 표현되며, 이를 프로세스의 궤적(trace) 이라고 한다. 처리기 행위의 특징은 다양한 프로세스들의 궤적이 어떻게 인터리빙 되는지를 보임으로써 표현될 수 있다.

복습타임
인터리빙(Interleaving)

• 여러 프로세스들이 서로 번갈아가면서 수행되는 것
• 번갈아 수행되는 시간 간격이 짧기 때문에 병렬수행하는 효과를 얻음

해당 예시를 통해 이해하자
현재 그림에서는 3개의 프로세스가 메모리 내에서 어떻게 배치되고 있는지를 보여준다. 세 프로세스는 모두 주기억장치에 완전히 적재된 프로그램으로 가정할 때, 처리기를 한 프로세스로부터 다른 프로세스로 교체(switch)하여 주는 작은 디스패처(dispatcher) 프로그램이 있다.

이 세 개의 프로세스는 인터리빙하며 계속해서 명령문을 번갈아가며 실행하게 되는데,
한 프로세스가 실행 중지 -> 디스패치에 기록 저장 -> 프로세스 교체 후 돌아올 때 기억(기록) 불러오기
의 과정을 인터리빙하면서 계속해서 실행하여 원할하게 프로세스의 명령문이 순서대로 진행되도록 만든다.

각 프로세스의 궤적, 즉 실행해야 하는 명령문들의 순서는 위와 같이 되어 있다.
이러한 궤적에서 어떻게 인터리빙 하면서 실행되는 걸까?

\우선 프로세스 A의 궤적대로 수행되지만 중간에 인터리빙 때문에 시간 만료(time-out) 가 되었다. 이후 프로세스 A를 냅두고 프로세스 B로 제어를 넘기기 위해 디스패처의 명령어가 실행된다. 이 때 디스패처의 명령어들은 100번대의 주소들이다.

이후 프로세스 B의 12000번대 명령어들이 4개가 실행된다. 해당 4개의 명령어가 수행된 뒤 입출력을 요청하고 기다리면서 다시 디스패처를 거쳐 제어는 프로세스 C로 이동한다. 프로세스 C 또한 이렇게 시간만료/입출력 요청마다 디스패처의 명령어를 수행한 후에 제어를 넘기는 과정을 반복한다. 여기서 알아두어야 할 것은, 명령어들이 다시 처음부터 명령어를 수행하는 것이 아닌, 프로세스 제어 블록을 통해 어떤 명령어까지 수행했는지를 알고 마지막으로 실행한 명령어의 다음 명령어부터 수행하게 된다.

해당 프로세스들이 수행하는 궤적을 따라 프로세스 상태를 표로 나타내면 이와 같이 표현할 수 있다.

2-상태(two-state) 프로세스 모델

운영체제는 프로세스의 수행을 제어하는 주요 업무가 있다. 이 과정에서 인터리빙 패턴을 결정하거나 일과 자원을 프로세스에게 할당하는 일 등이 있다. 이렇게 프로세스를 제어하기 위한 설계의 처음은 프로세스가 보여주어야 할 행태의 기술이다.

주어진 시점에 프로세스의 상태를 알려주는 모델을 구성할 수 있는데, 프로세스는 수행(Running, 실행)**과 비수행(Not Running, 비실행) 중의 한 상태를 가지게 된다.

새로운 프로세스 생성 시, 프로세스에 대한 프로세스 제어 블록을 생성하고 프로세스를 비수행 상태로 초기화시킨다. 이후 계속해서 운영체제 내에서 존재하며 자신이 수행될 기회를 기다리다가 수행중인 프로세스가 인터럽트 당하게 되면 디스패처가 수행할 새로운 프로세스를 선택하여 Running 상태로 돌리는데, 이 때 인터럽트 걸린 프로세스는 다시 비수행 상태로 돌아가게 된다.

위 구조에서는 프로세스가 어떻게 비수행 상태가 되고 어떤 프로세스가 수행 상태가 되는지를 보여준다.
큐에서는 각 프로세스의 제어 블록이 들어가고 디스패처가 이를 꺼내 수행시키다가 pause, 즉 I/O 요청이나 타이머 등이 실행되면 비수행상태로 다시 큐에 넣는 작업을 반복한다.

프로세스의 생성(creation)과 종료(termination)

위의 그림에서도 보이다시피 프로세스의 라이프사이클은 생성에서 시작되어 명령어의 수행을 반복하다가 명령어가 끝나게 되면 종료로 끝나게 된다.
그럼 이 생성과 종료에서 어떤 일이 일어날까?

프로세스 생성(creation)

기존의 프로세스 집단에 새로운 프로세스를 추가하고자 할 때 운영체제는 해당하는 프로세스를 관리하기 위해 필요한 자료구조를 만들고 주기억장치 내의 주소공간을 할당한다.

프로세스가 생성되는 이유는 네 가지가 있다.

생성 이유	설명
새로운 일괄처리 작업 (new batch job)	보통 테이프나 디스크를 통해 운영체제에 일괄처리 작업 제어 스트림이 제공된다. OS가 새로운 작업을 처리할 준비가 되면 다음에 수행할 일련의 작업 제어 명령을 읽어들인다.
대화형 로그온	사용자가 터미널에서 시스템에 로그온
서비스를 제공하기 위해 운영체제가 생성	운영체제는 사용자 프로그램을 대신해 어떤기능을 수행할 프로세스를 생성. 사용자가 따로 대기할 필요 없음
기존 프로세스에 의한 생성(spawn)	모듈화를 위해서나 병렬성을 활용하기 위해, 사용자 프로그램은 많은 프로세스의 생성을 명령 어떤 프로세스의 명시적인(explicit) 요청에 의해 새로운 프로세스를 생성 하나의 프로세스가 다른 프로세스를 생성할 때 부모(parent) 프로세스와 자식(child) 프로세스 구조로 이루어져 서로 통신 및 협력

프로세스 종료(termination)

어떤 컴퓨터 시스템이든 프로세스가 수행 완료를 표시할 수 있는 수단은 필수적으로 제공해야 한다.
일괄처리에서 작업의 종료는 중지(halt) 명령이나 명시적으로 운영체제 서비스 호출을 수행함으로써 이루어진다.
중지 명령어는 프로세스가 완료되었다는 사실을 운영체제에 통보하기 위해 인터럽트를 발생시키고, 대화식 응용 등을 통해 프로세스의 수행 완료를 통보한다.

정상적인 환경에서는 중지 명령어를 통해 프로세스를 종료하지만 오류 및 결함(fault) 상태로 프로세스가 종료될 수도 있다.

프로세스 종료 이유	설명
정상 완료	프로세스가 수행 완료를 알리는 운영체제 서비스 호출 수행
시간 한도 초과	프로세스가 명시된 전체 시간 한도보다 더 오래 수행되었을 경우
메모리 부족	프로세스가 시스템이 제공할 수 있는 메모리보다 더 많은 용량 요청
보호 오류	프로세스가 사용 금지된 자원이나 파일을 사용하려 하거나, 읽기전용 파일에 쓰기를 시도하는 등의 경우
경계범위 위반	프로세스가 접근이 허용되지 않은 메모리 위치에 접근하려 시도하는 경우
산술 오류	프로세스가 0으로 나누기와 같은 금지된 계산을 하거나 하드웨어 수용량보다 더 큰 숫자의 저장을 시도하는 경우
시간 초과	프로세스가 어떤 이벤트 발생을 명시된 최대 시간을 초과하여 기다리는 경우
입출력 실패	원하는 파일을 찾을 수 없거나 테이프에서 결함이 있는 부분을 만났을 때 처럼 명시된 최대 횟수 만큼의 시도 후에도 IO가 실패한 경우 혹은 하드웨어의 용도와 맞지 않은 IO 요청이 이루어졌을 경우
무효 명령어	프로세스가 존재하지 않는 명령어의 수행을 시도할 경우
특권 명령어	운영체제만의 예약된 명령어 사용 시도
데이터 오용	데이터 일부의 타입이 잘못되었거나 초기화되지 않았을 경우
오퍼레이터나 운영체제 간섭	어떤 이유(에러 등)으로 인하여 오퍼레이터/운영체제가 프로세스 종료
부모 종료	부모 프로세스가 종료될 때 자식 프로세스를 자동으로 종료시킬 수 있음
부모 요청	부모 프로세스는 자식 프로세스를 종료시킬 수 있는 권한을 가지고 있음

5-상태 모델(A Five-State Model)

위에서 제시한 2-상태 모델은 선입선출(FIFO) 리스트로 제시되어 처리기가 수행가능한 프로세스를 라운드 로빈(round-robin)형식으로 처리한다.

라운드 로빈(Round-robin)
프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간 단위로 CPU를 할당하는 방식. 일정한 시간을 주고 해당 시간이 만료되면 다른 프로세스들에게 제어를 넘겨준다.

하지만 이런 방식으로 작동하는 2-상태 모델의 문제는 비수행 상태에 있는 프로레스들이 아닌 IO연산이 완료되기를 기다리면서 블록되어 있는 프로세스들의 경우를 예외로 두지 않았다는 점이다. 그렇기 때문에 디스패처는 단순히 큐의 맨 끝에서부터 프로세스를 선택하는 것이 아닌, 큐 안을 살펴보고 블록의 여부와 큐에 가장 오래 머문 프로세스를 고려하여 프로세스에게 순서를 부여해야 한다.

이러한 상황을 보다 자연스럽게 처리하기 위해서는 비수행 상태를 준비(Ready) 상태와 블록(Blocked)상태로 분할하여 프로세스의 순서를 조율할 수 있는 모델을 제시했다.

• 수행(Running)
  - 현재 수행중인 프로세스
• 준비(Ready)
  - 기회가 주어지면 수행될 준비가 되어 있는 프로세스
• 블록/대기(Blocked/Waiting)
  - 입출력 연산 완료 등과 같은 어떤 이벤트가 발생할 때까지 수행될 수 없는 프로세스
• 생성(New)
  - 지금 막 생성되었지만, 운영체제에 의해 수행 가능한 프로세스 풀(pool)로의 진입이 아직 허용되지 않은 프로세스
  - 전형적으로 프로세스는 자신의 프로세스 제어 블록이 생성되었다 할지라도 그 당시까지 주기억장치에 적재되지 않음
• 종료(Exit)
  - 프로세스 수행이 중지(Halt) 되거나 어떤 이유로 중단(abort)되었기 때문에 운영체제에 의해 수행가능 프로세스 풀에서 방출된 프로세스

해당 모델에서 프로세스가 상태 전이를 일으키는 종류는 다음과 같다.

널(Null) -> 생성

새로운 프로세스가 정의되면 프로세스의 식별자 부여 및 프로세스를 관리하는데 필요한 테이블들이 할당 및 구축된다. 이 과정에서 프로세스는 생성의 단계로 시작한다. 프로세스의 생성 상태에서는 운영체제에 의해 필요한 프로세스 관련 정보는 주기억장치의 제어 테이블들에 유지되지만 프로세스 자체는 주기억장치가 아닌 보조 기억장치, 디스크 저장장치 등에 남아있다.

생성 -> 준비

운영체제가 새로 생성된 프로세스를 받아들일 준비가 되면 생성 상태에서 준비 상태로 전이시킨다. 대부분의 시스템은 존재하는 프로세스의 수에 제한을 두거나 프로세스에게 할당되는 가상메모리의 양을 제한한다.

준비 -> 수행

수행할 프로세스를 선택할 때가 되면 운영체제는 준비 상태에 있는 프로세스들 중에 하나를 선택하여 수행한다.

수행 -> 준비

수행에서 준비로 다시 돌아가는 경우는 프로세스가 자신에게 허용된 최대 처리기 시간이 만료되었을 경우이다. 시간만료가 되었을 때 프로세스를 다시 준비 큐에 넣어 바로 다음 명령어부터 수행할 수 있도록 한다.
다른 예로 준비 큐에 있는 다른 프로세스가 더 높은 우선순위를 부여하는 경우에도 그럴 수 있는데, 이 때는 인터럽트하여 다른 프로세스로 바꿀 수 있다. 이를 기존 프로세스를 선점(preemtion)했다고 표현한다.

수행 -> 종료

수행 중인 프로세스가 작업을 완료하거나 수행이 중단되면 운영체제는 그 프로세스를 종료시킨다.

수행 -> 블록

프로세스가 자원을 요구했지만 기다려야 하는 상태가 된다면 블록 상태로 전이된다. sys call이나 IO 동작, 프로세스 간의 통신이 대표적인 예인데, 운영체제는 즉시 수행할 수 없는 서비스이기 때문에 기다리는 블록 상태가 된 후에 필요한 처리가 모두 이루어지고 나서 다시 준비 상태로 돌아가게 된다.

블록 -> 준비

앞에서 말했듯 블록 상태의 프로세스는 자신이 기다리고 있던 이벤트가 발생하면 준비 상태로 전이된다.

준비 -> 종료/블록 -> 종료

준비/블록에서 종료 상태로 바로 전이될 수 있는 경우는 확실히 나타나있지 않지만 부모 프로세스가 자식 프로세스를 의도적으로 종료시키거나 그냥 종료되어 자식 프로세스가 함께 종료되는 경우 이렇게 바로 종료 상태로 전이된다.

Single vs. Multiple Blocked Quue

위와 같이 프로세스 상태를 5단계로 나눈 모델을 한 개의 큐로 만든 모델과 여러 개의 큐로 만든 큐로 나누어 모델을 생각해볼 수 있다.

한 개의 큐로 이루어진 모델의 경우 2-상태 모델과 큰 차이는 없지만 block상태를 모델에 따로 명시해 놓음으로써 블록 상태의 프로세스 또한 어떠한 과정을 통해 다시 준비 큐로 가는지 알 수 있다.

여러 개의 큐로 이루어진 큐잉 모델의 경우 처리 과정이 약간 다르다.
해당 모델의 경우 모든 이벤트의 종류마다 각각의 블록 큐를 생성한다. 이후 이벤트가 발생했을 때 모든 블록 큐를 전체적으로 조사하여 해당 이벤트를 기다리고 있던 프로세스를 일일이 찾아내야 한다. 대형 운영체제의 경우 블록 큐에 많은 양의 프로세스가 있을 수도 있는데 이를 각각 전부 블록 큐로 만드는 것보다 하나의 블록 큐를 넣는 것이 어찌보면 더 효율적일 수도 있다.

다른 멀티 블록 큐의 개선안으로는 우선순위에 따라서 우선순위 당 하나의 준비 큐를 두어 결정이 보다 빨리 이루어질 수 있도록 하는 방법이 있다.

보류된 프로세스(suspended)

스와핑(swapping)

앞의 큐는 모든 프로세스가 가상메모리를 사용하지 않는 시스템 하에서 굴러가고 있다고 생각할 때, 프로세스가 모두 주기억장치에 상주해야 한다는 단점이 있다. 이러한 경우 입출력 동작 시간이 처리기보다 훨씬 느리기 때문에 처리기가 수행을 끝내더라도 입출력 동작 시간동안 대기해야 하므로 처리기는 오랜 유휴시간을 가진다.

이를 해결하기 위해서는 더 많은 프로세스를 실행하는 것이 답일 수 있는데, 이를 위해서는 주기억장치의 확장이 필요하다. 하지만 주기억장치의 경우 확장을 한다 하더라도 기가바이트급으로 추가를 할 때마다 비용도 싸졌다고는 하지만 부담되는 가격이며, 대용량 메모리를 사용하더라도 프로세스의 무게가 무거워지면 어차피 똑같은 상태가 반복된다.

이럴 때 이를 해결하기 위한 방법으로 내놓은 것이 스와핑(swapping) 이다. 프로세스 일부나 전체를 주기억장치로부터 디스크로 옮겨 놓아 주기억장치에 있는 프로세스들 중에서 준비 상태에 있는 프로세스가 하나도 없다면, 운영체제가 블록된 프로세스들 중에 하나를 디스크로 보내고 보류 큐(suspended queue) 에 넣는다. 이후 주기억장치로부터 잠시 내쫓겨지거나 보류된 프로세스들이 존재하는 보류큐에 있는 다른 프로세스들을 주기억장치로 들여오거나 새로운 프로세스 요청을 받아들인 후 새롭게 도착한 프로세스를 가지고 수행을 계속 하는 방식이다.

이러한 스와핑 또한 IO 연산이기 때문에 문제를 더 악화시킬 수도 있는 여지가 있지만 디스크 입출력이 프린트나 테이프 등에 비해 시스템에서 가장 빠른 입출력 작업이기 때문에 성능이 향상될 가능성이 더 높다.

따라서 이와 같이 기존 5-상태 모델에서 suspend 상태를 추가함으로써 시스템의 개선을 노릴 수 있다.

이 때도 하나의 보류 상태를 추가한 것과 두 개의 보류 상태가 추가된 모델로 나눌 수 있는데, 하나의 보류 상태는 일반적인 보류 상태 하나만 있는데 비해 두 개의 보류 상태가 추가된 모델의 경우 추가된 상태로는 Blocked/Suspend 상태과 Ready/Suspend 상태가 있다.

• 블록/보류(Blocked/Suspend) 상태
  - 프로세스가 보조기억장치에 있고 사건을 기다리고 있는 상태
• 준비/보류(Blocked/Suspend) 상태
  - 프로세스가 보조기억장치에 있지만 주기억장치에 적재되면 즉시 수행될 수 있는 상태

swap in/out
swapping에서 사용하는 용어인swap in/out은 페이지를 swap area에서 물리 메모리로 들여오거나, 메모리에서 swap area로 내보내는 것을 의미한다.

이렇게 바뀐 상태 모델에서 새로 도입된 주요 전이는 다음과 같다.

블록 -> 블록/보류

준비된 프로세스가 하나도 없다면 적어도 하나의 블록된 프로세스를 스왑아웃시켜 블록되지 않은 다른 프로세스를 불러들일 공간을 마련한다.
준비 상태의 프로세스가 있어도 해당 전이가 발생할 수 있으며 수행중인 프로세스나 디스패치될 준비가 된 프로세스가 적절한 성능 유지를 위해 더 많은 주기억장치를 요구하는 경우, 해당 블록된 프로세스는 보류된다.

준비/보류 -> 준비

준비된 프로세스들이 주기억장치에 없으면 다른 준비/보류 상태에 있는 프로세스를 가져와 준비 상태로 전이시킨다

준비-> 준비/보류

운영체제는 주로 준비된 프로세스보다는 블록된 프로세스를 보류하려 하지만, 주기억장치에 충분히 큰 공간을 만들어야 하는 상황이라면 준비 상태의 프로세스를 보류하는 경우도 있다.
이 외에도 높은 우선순위의 블록된 프로세스보다는 낮은 우선순위의 준비 상태 프로세스를 보류할 수도 있다.

보류의 다른 용도

보류의 다른 용도에 대해 알아보기 전에 보류 상태의 프로세스 특징에 대해 알아보자.
1. 즉시 수행될 수 없다
2. 사건을 기다리고 있을 수도 있고 그렇지 않을 수도 있다. 사건을 기다리고 있을 경우 블록 상태의 조건은 보류 상태의 조건과는 독립적이므로 그 블록 상태를 해제시킬 사건이 발생하더라도 수행될 수 없다.
3. 에이전트(프로세스 자체나 부모 프로세스, 혹은 운영체제 등)가 프로세스의 수행을 막기 위해 그 상태를 보류로 만들어놓은 상태
4. 에이전트가 명시적으로 해제 명령을 내릴 때까지 보류 상태에서 벗어날 수 없다.

위와 같은 이유로 프로세스가 보류 상태로 이전되게 되는데, 이 때 다양한 이유를 통해 보류 상태로 이전시킬 수 있다.

이유	설명
스와핑	수행이 준비가 된 프로세스를 불러 들여오기 위해 운영체제는 충분한 주기억장치를 해제 요구하는 메모리가 같을 경우 메모리를 적게 차지하는 프로세스로 스와핑
운영체제의 다른 이유	후면 프로세스, 유틸리티 프로세스 또는 문제를 야기한다고 의심되는 프로세스를 운영체제가 보류시킴
대화식 사용자의 요청	사용자는 디버깅을 위해서 or 자원 사용과 관련해서 프로그램의 수행 보류
타이밍	주기적으로 수행되는 프로세스가 다음 주기까지 대기할 때 보류
부모 프로세스 요청	보류된 자식 프로세스의 검사나 수정을 위해 자식 프로세스의 수행 보류