[운영체제/OS] 2. 프로세스 Process

✍︎ 운영체제 내부구조 및 설계원리 제8판 (Operating Systems Internals and Design Principles) 을 정리하는 글입니다.

💪 이 장의 목적

• 프로세스를 정의하고 프로세스들과 프로세스 제어 블록들 사이의 관계를 설명할 수 있다.
• 프로세스 상태의 개념을 설명하고, 프로세스들의 상태 전이에 대해 설명할 수 있다.
• 프로세스들을 관리하기 위해, 운영체제가 사용하는 자료구조 및 자료구조 구성요소들의 목적을 나열하고 설명할 수 있다.
• 운영체제에서 프로세스 제어를 위한 요구사항들을 평가할 수 있다.
• OS코드의 실행에 관련된 이슈들을 이해할 수 있다.
• UNIX SVR4 프로세스 관리 기법을 설명할 수 있다.

인덱스

1. 프로세스(Process)란?

   • 정의
   • 구성 요소
   • 프로세스의 생성과 종료

   • 프로세스 상태

     • Two state process model
     • Five state process model
     • 보류상태를 가진 process state model

2. 프로세스의 구조와 속성

   • 프로세스 각각의 현재 상태 정보
   • Process Control Block

3. 운영체제 수행 방식

   • 선행 개념 세 가지

     • 수행 모드
     • 프로세스 생성 과정
     • 프로세스 교환

   • 운영체제의 특성을 고려한 접근 방법들

     • 비프로세스커널
     • 사용자 프로세스 내에서 수행
     • 프로세스 기반 운영체제

   • Unix 프로세스 관리

     프로세스(Process)란?

정의

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

구성 요소

• 프로그램 코드
• 관련데이터 집합
• 프로세스 제어 블록 (Process Control Block)
  운영체제에 의해 생성/관리된다.
  인터럽트를 당했던 프로세스의 수행이 재개될 때, 문제없이 수행을 재개할 수 있도록 정보를 유지해야한다.
  PCB는 운영체제가 다수의 프로세스트트 지원하고 멀티 프로세싱을 제공할 수 있게 하는 주요 도구
  자세한 설명은 여기에서 확인

프로세스의 생성(Creation)과 종료(Termination)

생성 Creation

프로세스가 생성되는 이유는 다음과 같다.

• 새로운 일괄처리 작업 (New batch job)
• 대화형 로그온
• 서비스 제공을 위해서 운영체제가 생성
• 기존 프로세스에 의한 생성(Spawn) = Process spawning
  모듈화 또는 병렬성을 위해 프로그램은 프로세스 명령을 할 수 있다.
  프로세스(자식 child) made by 프로세스(부모 parent)

종료 Termination

어떤 컴퓨터 시스템이든 프로세스가 수행 완료를 표시할 수 있는 수단을 필수적으로 제공해야한다.
프로세스가 종료되는 이유는 다음의 예가 있다.

프로세스의 상태

Two-state process model

• 프로세스 상태 종류

  • Running(수행)
  • Not Running(비수행)

운영체제는 새로운 프로세스를 생성할 때 다음과 같은 과정을 거친다.

1. 프로세스와 함께 해당 프로세스의 PCB도 생성
2. 프로세스를 시스템 내에 비수행(Not Running)상태로 초기화
3. 운영체제에 의해 수행
4. 프로세스가 인터럽트를 당하면 디스패처(Dispatcher)가 수행할 새로운 프로세스를 선택한다.
   인터럽트 당한 프로세스의 상태는 수행(Running)상태에서 비수행(Not Running)상태로 전이되며, dispatcher에 의해 선택된 프로세스의 상태가 수행상태로 전이된다.

디스패처는 큐에서 다음에 수행할 프로세스를 선택한다. 이때 큐는 FIFO 자료 출입의 자료구조이며, 라운드로빈 형식으로 프로세스를 선택하는데, 이로 인해 발생하는 문제를 해결하기 위해 five state process model이 고안되었다.

Five-state process model

• 프로세스 상태 종류

  • New(시작)
    막 생성되었으나 프로세스 풀(pool) 진입 이전의 상태. 즉, 새로운 프로세스는 PCB가 생성되어도 주기억장치에 적재되지 않는다. 운영장치는 프로세스 생성 조치는 했으나 수행 조치는 하지 않은 상태이다. 관련 정보는 주 기억장치에 있지만 프로세스 자체는 주기억장치에 없다.
  • Ready(준비)
    수행될 준비가 되어있는 상태
  • Running(수행)
    현재 수행 중인 프로세스
  • Blocked/Waiting(블록/대기)
    입출력 연산 완료 등 어떤 이벤트 발생 전까지 수행될 수 없는 상태
  • Exit(종료)
    프로세스 수행 중지(halt) 또는 어떤 이유로 중단(abort)되어 운영체제에 의해 수행가능 프로세스 풀에서 방출된 프로세스
    
    
    

🟡 주요 전이

• Null -> Creation

  • 어떤 프로그램을 수행하기 위한 새로운 프로세스 생성

• Creation -> Running

  • 운영체제가 프로세스를 프로세스 풀에 적재할 준비가 되었을 때
    (시스템 성능 저하를 막기 위해 대부분의 시스템은 프로세스 수에 제한이 있거나 할당되는 가상메모리 용량에 제한을 둔다.)

• Running -> Exit

  • 프로세스 작업 완료 또는 중단 시

• Running -> Ready

  • 일반적으로 이 전이는 수행 중인 프로세스가 할당된 처리기 이용 시간을 모두 사용했을 경우에 발생한다.
    이 전이가 발생한 프로세스는 운영체제에 의해 선점(Preemption)당했다고 할 수 있다.
    이런 류의 시간 정책은 프로세스에 우선순위를 부여하는 시스템일 경우에 더 중요하다.

• Running -> Blocked

  • 프로세스가 운영체제가 즉시 수행할 수 없는 서비스를 요청하거나, 입출력 동작 같은 프로세스 수행 재개 전 완료해야하는 작업을 시작하거나, 다른 프로세스로부터 데이터 또는 메세지를 기다리는 등의 상황에서 일어나는 전이

• Blocked -> Ready

  • 기다리던 이벤트 발생 시

• Ready -> Exit 또는 Blocked -> Exit

  • 부모 프로세스의 종료로 인해 자식 프로세스가 종료될 때를 예시로 들 수 있다.

보류 상태를 가진 process state model

• 문제 상황

  1. 입출력 동작 속도가 처리기 계산 속도보다 매우 느리기 때문에 단일 프로그래밍 시스템의 처리기는 대부분 유휴(idle) 상태이다.
  2. 가상 메모리를 사용하지 않는 시스템이라고 가정했을 때, 수행될 프로세스들은 모두 주기억장치에 완전히 적재되어야 한다.
     ☞ 이 문제를 해결하기 위해 Multiple Blocked Queue 모델을 사용하지만 문제가 완전히 해결되지 않는다. (처리기 수행 속도가 매우 빠르기 때문)

• 어떻게 처리기의 이용률을 높일 것인가?

  • 해결 방안 1) 주기억장치 확장
    더 많은 프로세스를 적재하기 위해 주기억장치의 용량을 확장한다. 하지만 이 방법의 경우 두 가지 문제가 발생한다.

    • 주기억장치 바이트당 가격은 낮아져도 기가 바이트 만큼의 용량 추가 시 비용 문제 발생
    • 메모리 가격의 하락과 동시에 프로그램의 메모리 요구량이 증가해 결과적으로는 프로세스 수가 증가하는 것이 아니라 크기가 늘어나는 것

  • 해결 방안 2) Swapping
    프로세스의 일부 또는 전체를 주기억장치에서 보조기억장치(예: 디스트)로 옮기는 것

    • 주기억장치의 프로세스 중 준비 상태에 있는 프로세스가 단 한 개도 없다면 OS는 블록된 process들 중 하나를 디스크로 보내고 suspended queue(보류 큐)에 넣는다. 이를 통해 주기억장치의 여유 용량을 만들 수 있다.
    • OS는 보류 큐에 있는 다른 process를 주기억장치로 들여오거나, 새로운 프로세스 요청을 받아들인 후 새로운 프로세스로 수행을 지속한다.
      ☝️ 스와핑은 입출력 연산의 일종이라 문제 상황을 악화시킬 수도 있지만, 디스크 입출력은 입출력 연산 중 상대적으로 빠른 입출력 작업이므로 일반적인 경우에는 스와핑을 통해 성능 향상을 기대할 수 있다.

    즉, 주기억장치에 있는 모든 프로세스가 blocked 상태일 때, 운영체제는 한 프로세스를 디스크에 전송한다. 이때 생긴 여유 공간에 다른 프로세스를 적재할 수 있고, 디스크에 전송된 프로세스의 상태는 보류 상태(suspended)이다.
    
    

• 운영체제는 디스크에서 어떤 프로세스를 주기억장치로 가져와야할까?

  • Option 1 새롭게 생성된 프로세스
  • Option 2 이전에 보류되었던 프로세스 ✔️ : 시스템 전체 부하를 증가시키지 않고 프로세스에게 서비스를 제공하기 위해서

• 이전에 보류되었던 프로세스를 가져왔을 때, 만약 해당 프로세스가 여전히 수행될 준비가 되지 않았다면 swapping은 의미가 없어진다. 따라서 보류 상태에 있는 것중에 준비가 된 것이 있는지 구별하기 위한 4가지의 상태가 추가된다.

• 보류 상태 프로세스의 특성

  • 즉시 수행될 수 없다.
  • 사건 발생을 기다리고 있을 수도 있고 아닐 수도 있다.
  • 에이전트(프로세스 자체, 부모 프로세스, 운영체제)가 수행 막기 위해 상태를 보류로 바꿨다.
  • 에이전트의 해제 명령 있기 전까지는 보류 상태 탈출 불가
    

• 보류에 대한 이유

  • 스와핑
  • 운영체제의 다른 이유
  • 대화식 사용자의 요청 (ex: Debugging)
  • 타이밍
  • 부모 프로세스의 요청

🟡 보류 상태가 둘인 상태 전이도의 주요 전이

• 블록 -> 블록/보류

  • 준비된 프로세스가 하나도 없을 때 주기억장치의 용량을 늘리기 위해 일어나는 전이
  • 하지만 준비 상태의 프로세스가 있어도 수행 중인 프로세스가 성능 유지를 위해 더 많은 용량을 요구할 때에도 전이 발생 가능
    
    

• 준비/보류 -> 준비

  • 준비된 프로세스가 주기억장치에 없으면 다른 프로세스 반입 필요
  • 준비/보류 상태 프로세스의 우선순위가 준비 상태 프로세스의 우선순위보다 높을 때에도 전이 발생 가능
  • 따라서 설계자는 스와핑 최소보다는 높은 우선순위 프로세스를 가져오는 것에 우선순위를 둘 수도 있다.
    
    

• 준비 -> 준비/보류

  • 대부분의 상황에서 운영체제는 블록 프로세스를 보류하지만 때때로 준비 상태 프로세스를 보류하는 것이 공간 생성의 유일한 방법이라면 이 전이가 가능하다.
  • 또는 곧 준비 상태가 될 블록 프로세스의 우선 순위가 준비 상태 프로세스의 우선순위보다 높을 때에도 가능한 전이
    
    

🟠 보류 상태가 둘인 상태 전이도의 그 밖에 고려할만한 전이들

• 생성 -> 준비/보류 또는 생성 -> 준비
  
  

• 블록/보류 -> 블록

  • 별로 필요 없는 전이 상태로 볼 수 있지만, 만약 주기억장치에 공간이 있고 준비/보류 큐 프로세스들보다 우선순위 높은 프로세스가 블록/보류 큐에 있을 때, 블록/보류 프로세스의 이벤트가 곧 일어나면 이 상태의 전이가 일어나는 것이 타당하다.
    
    
• 수행 -> 준비/보류
  
  
• 임의 상태 -> 종료
  
  
  

☝️ 지금까지 가상메모리가 사용되지 않으며 프로세스 전체가 주기억장치 내부 또는 외부에 있는 환경을 가정했다. 하지만 가상메모리 환경/기법을 사용하는 환경에서도 때로는 명시적으로 완전히 프로세스들이 swap out되어야 할 필요가 있다.

프로세스 구조 및 속성

운영체제가 프로세스들을 제어하고, 할당될 자원들을 관리하기 위해 필요한 정보는 무엇인가?

✔️ 프로세스 각각의 현재 상태 정보

• 메모리 테이블: 주기억장치와 보조기억장치의 track을 유지하기 위해 사용됨

  • 프로세스에 할당된 주기억장치
  • 프로세스에 할당된 보조기억장치
  • 주기억장치 또는 가상메모리 블록들에 대한 보호속성
  • 가상메모리 관리를 위해 필요한 정보
• 입출력 테이블: 입출력 장치와 컴퓨터 시스템의 채널들을 관리하기 위해 사용됨

• 파일 테이블: 파일 관리 시스템에 의해 유지/사용되는 경우 운영체제는 정보를 극히 일부만 유지하거나 전혀 유지하지 않음

  • 파일 존재 여부
  • 보조기억장치에 저장된 파일의 위치
  • 현재 상태
  • 그밖의 다른 속성들에 대한 정보

• 프로세스 테이블: 위 세 가지 테이블들은 모두 프로세스를 위해 관리하는 것이기 때문에, 프로세스 테이블에서는 이 자원들에 대한 참조가 직/간접적으로 이뤄진다.

  • 프로세스 위치 Location in memory

    • 프로세스는 프로그램 & 데이터(관련 지역, 전역 변수들), 프로시저 호출들의 트랙과 스택, 수많은 속성들로 이뤄져있다.
    • 운영체제는 그 속성들을 사용하여 프로세스를 제어한다.
    • 프로세스에서 사용되는 속성의 집합 = 프로세스 제어 블록 (Process Control Block)
      📍즉, 운영체제는 프로세스를 제어하기 위한 속성 정보들을 PCB에서 얻고, PCB는 프로세스 이미지에 있으므로 결과적으로 프로세스 이미지에 접근해야한다.
    • 프로세스 이미지의 위치는 메모리 관리 기법에 따라 달라지는데 가장 간단한 방법은 프로세스 이미지를 메모리의 연속된 인접 블록에 위치시키는 것이다. 인접블록은 보조기억장치(주로 디스크)에서 관리됨
    • 운영체제는 프로세스 이미지의 일부를 주기억장치에 유지하여 프로세스를 관리할 수 있고, 수행을 위해서는 이미지의 전체를 주기억장치(적어도 가상메모리 내)에 적재한다.
    • 최근에는 프로세스의 일부분만 주기억장치에 상주시켜도 관리 뿐만 아니라 수행까지 할 수 있게끔 비연속적으로 물리적 메모리를 할당/회수하는 페이징 하드웨어를 가정한다.

Process Control Block

프로세스 속성 집합

구성

• 프로세스 식별 Process identification

  • 식별자: 프로세스 식별자, 프로세스를 생성한 프로세스의 식별자, 사용자 식별자

• 처리기 상태 정보 Processor state information

  • 사용자가 사용가능한 레지스터
  • 제어 레지스터&상태 레지스터: Program counter, 조건 코드(condition codes), 상태 정보 => 조건 코드와 상태 정보는 Program status word에 저장된다.
  • 스택 포인터(stack의 top을 가리킴): 프로시저와 시스템 호출의 매개변수&호출 주소를 저장하기 위한 스택

• 프로세스 제어 정보 Process control information

  • 운영체제의 스케줄링 기능 수행을 위한 스케줄링과 상태 정보: 프로세스 상태, 우선순위, 스케줄링 관련 정보, 스케줄링 알고리즘에 따라 요구되는 정보, 이벤트
  • 자료구조화(Data structuring)
  • 프로세스간 통신(IPC)
  • 프로세스 권한(Process privileges)
  • 메모리 관리
  • 자원의 소유권과 이용률

역할

• 운영체제에서 가장 중요한 자료구조
• 운영체제의 모든 모듈(스케줄링, 자원 할당, 인터럽트 처리)은 PCB에 접근 또는 PCB를 수정할 수 있다.
  따라서 PCB의 집합은 운영체제의 상태를 정의한다고 말할 수있다.

☝️ 모든 모듈이 PCB에 접근하는 것은 두 가지 문제를 야기한다. 정확하게는 접근(접근 허용은 쉽다)보다 보호 측면에서 문제가 발생한다.

1. 인터럽트 핸들러 같은 단일 루틴의 버그가 PCB에 손상을 줄 가능성이 있고, 그로 인해 해당 프로세스를 관리라는 시스템 기능이 파괴될 수 있다.
2. PCB의 구조와 의미(sementics) 부분 설계가 변경되면 운영체제 모듈이 영향을 받게 될 것이다.

이 문제들은 “운영체제의 모든 루틴들은 핸들러 루틴*을 통해야 한다”는 조건을 통해 해결될 수 있다.
핸들러 루틴: PCB를 보호하는 루틴으로 PCB에 대한 읽기/쓰기 연산을 제어하는 유일한 조정자 역할을 한다.

운영체제 수행 방식

운영체제 수행 방식에 대해 알아보기 전, 먼저 알아야할 개념 세 가지

1. 수행 모드 (Modes of Execution)

• 사용자 모드 (User mode) - 사용자 프로그램들이 주로 수행되는 모드

• 커널 모드 (Kernel mode) = 시스템 모드 system mode = 제어 모드 control mode
  
  

  📍 두 가지 수행 모드로 구별하는 이유

  운영체제 및 프로세스 제어 블록과 같은 주요 운영체제 테이블들을 사용자 프로그램으로부터 보호하기 위해.
  커널 모드에서 수행되는 소프트웨어는 처리기&모든 명령어들, 레지스터들, 메모리를 완전히 제어할 수 있다. 이러한 수준의 제어가 사용자 프로그램에는 필요하지 않다.
  
  

• 프로그램 상태 워드(PSW)의 한 비트를 이용해 프로세스가 현재 어떤 모드에서 수행되는지 나타낼 수 있다.

  • 커널 모드로 바뀌는 경우: 사용자가 운영체제 서비스 호출 || 인터럽트가 운영체제 서비스를 촉발할 때
  • 사용자 모드로 바뀌는 경우: 제어가 운영체제 서비스에서 사용자 서비스로 복귀할 때

Plus 운영체제 커널의 주요 기능

2. 프로세스 생성 과정

1. 새 프로세스에 식별자 할당/부여. 이때 주프로세스 테이블에 해당 프로세스의 항목이 추가된다.
2. 프로세스 이미지의 요소들(프로그램 및 데이터, 사용자 스택, PCB)을 프로세스에 저장하기 위한 공간을 할당한다.

3. 프로세스 제어 블록 초기화

   • 프로세스 식별: {해당 프로세스 ID, 부모 프로세스 ID, 사용자 식별자}
   • 처리기 상태 정보: {pc = 프로그램 진입점, system stack pointer = 프로세스 스택 경계 정의, .etc}
   • 프로세스 제어 정보: {표준 기본값과 프로세스를 위해 요청된 속성에 근거하여 초기화 됨 - 우선순위는 특별한 명시가 없으면 최하위 순위로 설정됨}

4. 적절한 연결 (linkage) 설정

   • 예시
     if 스케줄링 큐가 연결리스트: 새로운 프로세스는 준비 or 준비/보류 리스트에 놓여져야 한다.
5. 다른 자료구조 생성/확장

3. 프로세스 교환 (Process switching)

• 교환 시점 프로세스 교환은 언제 이뤄져야 할까? ☝️ 수행 중인 프로세스가 운영체제로 제어를 넘길 때, 프로세스 교환이 가능하다.

  • 이유 1: 인터럽트

    • 원인: 현재 명령어 수행의 외부 👉 비동기적인 외부 사건에 반응
    • Clock interrupt: 할당 시간 만료 시 다른 프로세스 디스패치
    • I/O interrupt: 입출력 동작 발생 시, 해당 동작을 기다리던 프로세스들을 준비 상태로 전이한 후 수행하던 것을 수행할지, 우선순위가 높은 것을 수행할지 결정
    • Memory fault: 처리기가 주기억장치에 없는 워드 요청 시, 운영체제는 보조기억장치로부터 해당 워드를 포함한 블록을 가져오기 위헤 입출력 요청 후 해당 프로세스를 블록 처리한다. 그 후 다른 프로세스의 처리를 위해 프로세스 교환

  • 이유 2: 트랩 Trap

    • 원인: 현재 명령어 수행과 관련 👉 오류나 예외 상황 처리
    • OS는 관련 오류/조건이 치명적인지 아닌지 판단 후 여부에 따라 프로세스를 교환하거나 수행을 재개

  • 이유 3: SuperVisor Call

    • 원인: 명시적 요청 👉 OS기능 호출

• 📍 프로세스 교환 (Process switching) VS 모드 전환 (Mode switching)

  • 가정 상황
    명령어 사이클에서 인터럽트 검사시 인터럽트 신호가 있다면 처리기는
    1. pc값을 인터럽트 핸들러 프로그램 시작 주소로 설정
    2. 인터럽트 처리 코드의 특권 명령어 사용을 위해 사용자 모드 -> 커널 모드로 수행 모드 전환

    이 때 인터럽트 된 프로세스의 문맥은 추후 복귀를 위해 프로그램 PC에 저장된다. 인터럽트 처리 후 만약 수행되던 프로세스를 재개하는 것이 아니라 다른 프로세스로의 교환이 요구되면 저장 또는 처리할 것들이 증가한다.

  위의 상황을을 보면 인터럽트가 발생했다고 해서 프로세스 교환이 무조건적으로 이뤄져야 하는 것은 아니라는 것을 알 수 있다.

  즉, 모드 전환은 현재 수행상태 프로세스의 상태 변경없이 가능하다는 것을 의미하며, 따라서 문맥 저장 또는 복구 시 생기는 오버헤드는 없다.

  그에 반해 프로세스 교환은 아래와 같은 동작들이 차례로 수행되어야 한다.

  1. pc & 다른 레지스터들을 포함한 처리기 문맥 저장
  2. 현재 수행 중인 pcb 갱신, 프로세스 상태 전이
  3. 프로세스의 pcb를 적절한 큐로 이동
  4. 다음 프로세스 선택
  5. 선택된 프로세스의 pcb 갱신 및 수행 상태 전이
  6. 메모리 관련 자료구조 갱신
  7. 처리기 문맥 복원

  ☞ 프로세스 상태 전이를 포함한 프로세스 교환은 모드 전환과는 다르며 상당히 많은 작업을 요구한다.

운영체제의 특성을 고려한 접근 방법들

• 운영체제의 특성

  • 운영체제 또한 처리기에 의해 수행되는 프로그램의 집합
  • 제어를 자주 양도하고 또 그를 돌려받기 위해 처리기에 의존적

📍 운영체제를 하나의 프로세스로 볼 수 있다면, 어떻게 관리해야할까?

✔️ 비프로세스 커널 Nonprocess kernel

• 많은 오래된 운영체제에서 쓰이는 방법
• 모든 프로세스의 외부에서 운영체제 커널을 수행시키는 방법

if 현재 수행 중인 프로세스가 인터럽트 당하거나 svc 요청:  
    프로세스 문맥 저장 후 제어는 처리기에서 커널(운영체제)로 넘어감

이때 커널은 자신이 사용할 메모리 영역, 프로시저 호출/복귀 위한 시스템 스택을 갖고있다.

☝️ 프로세스 개념은 사용자 프로그램에만 적용되고, 운영체제 코드는 분리 개체로 수행되며 특권 모드에서 동작함.

✔️ 사용자 프로세스 내에서 수행 Execution within User Processes

• 이 방법에서 운영체제는 다양한 기능들을 수행하기 위해 사용자가 호출하는 루친들의 집합이다.
• 운영체제는 사용자 프로세스 내에서 수행된다.
• 운영체제는 n개의 프로세스 이미지를 관리 중

if 인터럽트, 트랩, svc 발생:
    처리기는 커널 모드로 전이됨
    제어는 운영체제로 옮겨감
    하지만 여전히 사용자 프로세스 내에서 수행이 계속되고 있다.
    => 프로세스 교환 X, 모드 전환 O

• ☝️ 이 방식의 이점

  • 프로세스 교환 없이 재개 가능
    하지만 프로세스 교환이 필요할 때에는 제어가 프로세스 교환 루틴으로 넘어가며 이 작업은 프로세스의 외부에서 이뤄진다.

사용자 프로세스 내에서 운영체제 루틴이 수행되어도 사용자 모드/커널 모드로 분리되어 있기 때문에 사용자는 운영체제 루틴에 간섭/관여 불가

프로세스 내에서 사용자 프로그램과 운영체제 프로그램 모두 수행 가능하며, 다양한 사용자 프로세스에서 수행되는 운영체제 프로그램은 동일하다.

✔️ 프로세스 기반 운영체제 Process-Based Operating System

• 운영체제를 시스템 프로세스들의 집합으로 구현

• 커널 소프트웨어 부분은 다른 방식들과 같이 커널 모드에서 수행되지만 커널의 주요기능들은 여러 개의 분리된 프로세스로 구성된다.

• ☝️ 이 방식의 이점

  • 운영체제의 모듈화를 통해 프로그램 설계 원칙에 충실할 수 있다.
  • 중요하지 않은 운영체제 기능은 개별 프로세스로 쉽게 구현 가능
  • 다중처리기나 멀티 컴퓨터 환경에서 유용
  • 운영체제에 의해 제공되는 몇 가지 서비스를 지정된 처리기에서 수행하며 성능 향상 가능

UNIX SVR4의 프로세스 관리