운영 체제 소개

헤이 하브르! 제 생각에는 흥미로운 문헌 인 OSTEP에 대한 일련의 기사 번역을 여러분의 관심을 끌고 싶습니다. 이 자료는 유닉스 계열 운영 체제의 작업, 즉 프로세스, 다양한 스케줄러, 메모리 및 최신 OS를 구성하는 기타 유사한 구성 요소 작업에 대해 매우 깊이 논의합니다. 여기에서 모든 자료의 원본을 볼 수 있습니다. 여기에. 비전문적으로(상당히 자유롭게) 번역했지만 일반적인 의미를 유지했으면 합니다.

이 주제에 대한 연구실 작업은 여기에서 찾을 수 있습니다.

• 기발한: 페이지.cs.wisc.edu/~remzi/OSTEP/Homework/homework.html
• 기발한: github.com/remzi-arpacidusseau/ostep-code
• 내 개인적인 적응: github.com/bykvaadm/OS/tree/master/ostep

기타 부품 :

• 1부: 소개

에서 내 채널을 확인할 수도 있습니다. 이야기 =)

OS가 사용자에게 제공하는 가장 기본적인 추상화인 프로세스를 살펴보겠습니다. 프로세스의 정의는 매우 간단합니다. 실행 중인 프로그램. 프로그램 자체는 디스크에 있는 생명이 없는 것입니다. 이는 일련의 명령이며 실행을 기다리는 일부 정적 데이터일 수도 있습니다. 해당 바이트를 가져와 실행하여 프로그램을 유용한 것으로 변환하는 것은 OS입니다.
대부분의 경우 사용자는 동시에 두 개 이상의 프로그램을 실행하기를 원합니다. 예를 들어 노트북에서 브라우저, 게임, 미디어 플레이어, 텍스트 편집기 등을 실행할 수 있습니다. 실제로 일반적인 시스템은 수십 또는 수백 개의 프로세스를 동시에 실행할 수 있습니다. 이 사실은 시스템 사용을 더 쉽게 만들고, CPU가 비어 있는지 여부에 대해 걱정할 필요가 없으며, 프로그램을 실행하기만 하면 됩니다.

이는 문제를 제기합니다. 어떻게 많은 CPU가 있다는 환상을 제공할 수 있을까요? 물리적 CPU가 하나만 있는 경우에도 OS는 어떻게 CPU 수가 거의 무한하다는 환상을 만들 수 있습니까?

OS는 CPU 가상화를 통해 이러한 환상을 만듭니다. 하나의 프로세스를 시작한 다음 중지하고 다른 프로세스를 시작하는 등의 과정을 통해 OS는 실제로는 하나 이상의 물리적 프로세서가 있을 때에도 가상 CPU가 많다는 착각을 유지할 수 있습니다. 이 기술을 CPU 리소스를 시간별로 나누기. 이 기술을 사용하면 사용자는 원하는 만큼 많은 동시 프로세스를 실행할 수 있습니다. 이 솔루션의 비용은 성능입니다. 여러 프로세스가 CPU를 공유하는 경우 각 프로세스가 더 느리게 처리되기 때문입니다.
CPU 가상화를 구현하고 특히 이를 잘 수행하려면 OS에 낮은 수준과 높은 수준의 지원이 모두 필요합니다. 낮은 수준의 지원이 호출됩니다. 메커니즘 기능의 필수 부분을 구현하는 하위 수준 메서드 또는 프로토콜입니다. 이러한 기능의 예로는 OS에 하나의 프로그램을 중지하고 프로세서에서 다른 프로그램을 실행할 수 있는 기능을 제공하는 컨텍스트 전환이 있습니다. 이 시분할은 모든 최신 운영 체제에서 구현됩니다.
이러한 메커니즘 위에는 "정책"의 형태로 OS에 내장된 일부 논리가 있습니다. 정책 운영 체제에 대한 특정 의사 결정 알고리즘입니다. 예를 들어, 이러한 정책은 (명령 목록에서) 먼저 시작해야 할 프로그램을 결정합니다. 예를 들어 이 문제는 다음과 같은 정책으로 해결됩니다. 스케줄러(스케줄링 정책) 솔루션을 선택할 때 시작 기록(마지막 몇 분 동안 가장 오랫동안 실행된 프로그램), 이 프로세스가 전달하는 로드(실행된 프로그램 유형), 성능 지표(시스템이 실행되었는지 여부)와 같은 데이터를 기준으로 안내됩니다. 대화형 상호 작용 또는 처리량) 등에 최적화되어 있습니다.

추상화: 프로세스

운영 체제에 의해 실행되는 실행 프로그램의 추상화를 우리는 이렇게 부릅니다. 방법. 앞서 언급했듯이 프로세스는 어느 순간에나 실행되는 프로그램일 뿐입니다. 이 프로그램이 실행되는 동안 액세스하거나 영향을 미치는 다양한 시스템 리소스로부터 요약 정보를 얻을 수 있는 프로그램입니다.
프로세스의 구성요소를 이해하려면 시스템 상태, 즉 프로그램이 작동 중에 무엇을 읽거나 변경할 수 있는지를 이해해야 합니다. 언제든지 프로그램 실행에 중요한 시스템 요소를 이해해야 합니다.
프로세스에 포함된 시스템 상태의 명백한 요소 중 하나는 다음과 같습니다. память. 지침은 메모리에 있습니다. 프로그램이 읽거나 쓰는 데이터도 메모리에 있습니다. 따라서 프로세스가 주소를 지정할 수 있는 메모리(주소 공간이라고 함)는 프로세스의 일부입니다.
또한 시스템 상태의 일부는 레지스터입니다. 많은 명령어는 레지스터 값을 변경하거나 그 값을 읽는 것을 목표로 하므로 레지스터도 프로세스 작동의 중요한 부분이 됩니다.
머신 상태는 일부 특수 레지스터로부터도 형성된다는 점에 유의해야 합니다. 예를 들어, IP - 명령어 포인터 — 프로그램이 현재 실행 중인 명령어에 대한 포인터입니다. 도 있습니다 스택 포인터 그리고 그와 관련된 프레임 포인터, 함수 매개변수, 지역 변수 및 반환 주소를 관리하는 데 사용됩니다.
마지막으로 프로그램은 ROM(읽기 전용 메모리)에 액세스하는 경우가 많습니다. 이 "I/O"(입력/출력) 정보에는 현재 프로세스에서 열려 있는 파일 목록이 포함되어야 합니다.

프로세스 API

프로세스 작동 방식에 대한 이해를 높이기 위해 운영 체제 인터페이스에 포함되어야 하는 시스템 호출의 예를 연구해 보겠습니다. 이러한 API는 모든 OS에서 어떤 형태로든 사용할 수 있습니다.

● 만들기 (생성): OS에는 새 프로세스를 생성할 수 있는 몇 가지 방법이 포함되어 있어야 합니다. 터미널에 명령을 입력하거나 아이콘을 두 번 클릭하여 애플리케이션을 시작하면 OS에 호출이 전송되어 새 프로세스를 만든 다음 지정된 프로그램을 시작합니다.
● 제거: 프로세스를 생성하기 위한 인터페이스가 있기 때문에 OS는 프로세스를 강제로 제거하는 기능도 제공해야 합니다. 대부분의 프로그램은 실행되면서 자연스럽게 자체적으로 시작되고 종료됩니다. 그렇지 않으면 사용자는 프로세스를 종료할 수 있기를 원하므로 프로세스를 중지하는 인터페이스가 유용할 것입니다.
● 기다림 (대기): 때로는 프로세스가 완료될 때까지 기다리는 것이 유용하므로 대기 기능을 제공하는 일부 인터페이스가 제공됩니다.
● 기타 제어 (다양한 제어): 프로세스를 종료하고 기다리는 것 외에도 다양한 제어 방법이 있습니다. 예를 들어, 대부분의 운영 체제는 프로세스를 정지(특정 기간 동안 실행을 중지)한 다음 다시 시작(실행을 계속)하는 기능을 제공합니다.
● Status (상태): 실행 기간이나 현재 상태 등 프로세스 상태에 대한 일부 정보를 얻기 위한 다양한 인터페이스가 있습니다.

프로세스 생성: 세부정보

흥미로운 점 중 하나는 프로그램이 정확히 어떻게 프로세스로 변환되는지입니다. 특히 OS가 프로그램을 선택하고 실행하는 방법. 프로세스가 정확히 어떻게 생성되는지.
우선, OS는 프로그램 코드와 정적 데이터를 메모리(프로세스 주소 공간)에 로드해야 합니다. 프로그램은 일반적으로 일부 실행 가능 형식으로 디스크나 솔리드 스테이트 드라이브에 위치합니다. 따라서 프로그램과 정적 데이터를 메모리에 로드하는 프로세스에서는 OS가 디스크에서 해당 바이트를 읽고 메모리 어딘가에 배치할 수 있어야 합니다.

초기 운영 체제에서는 로딩 프로세스가 적극적으로 수행되었습니다. 이는 프로그램이 시작되기 전에 전체 코드가 메모리에 로드되었음을 의미합니다. 최신 운영 체제에서는 이 작업을 느리게 수행합니다. 즉, 프로그램 실행 중에 필요할 때만 코드나 데이터 조각을 로드합니다.

코드와 정적 데이터가 OS 메모리에 로드되면 프로세스를 실행하기 전에 수행해야 할 몇 가지 작업이 더 있습니다. 스택에 일정량의 메모리를 할당해야 합니다. 프로그램은 지역 변수, 함수 매개변수 및 반환 주소에 스택을 사용합니다.. OS는 이 메모리를 할당하여 프로세스에 제공합니다. 스택은 일부 인수를 사용하여 할당할 수도 있습니다. 특히 argc 및 argv 배열과 같이 main() 함수의 매개변수를 채웁니다.

운영 체제는 프로그램 힙에 일부 메모리를 할당할 수도 있습니다. 힙은 프로그램에서 동적으로 할당된 데이터를 명시적으로 요청하는 데 사용됩니다.. 프로그램은 함수를 호출하여 이 공간을 요청합니다. malloc () 함수를 호출하여 명시적으로 지웁니다. 무료(). 힙은 연결된 시트, 해시 테이블, 트리 등과 같은 데이터 구조에 필요합니다. 처음에는 소량의 메모리가 힙에 할당되지만 시간이 지나면서 프로그램이 실행되면서 힙은 라이브러리 API 호출 malloc()을 통해 더 많은 메모리를 요청할 수 있습니다. 운영 체제는 이러한 호출을 만족시키기 위해 더 많은 메모리를 할당하는 프로세스에 참여합니다.

운영 체제는 특히 I/O와 관련된 초기화 작업도 수행합니다. 예를 들어, UNIX 시스템에서 각 프로세스에는 기본적으로 표준 입력, 출력 및 오류에 대한 3개의 열린 파일 설명자가 있습니다. 이러한 핸들을 통해 프로그램은 터미널의 입력을 읽을 수 있을 뿐만 아니라 화면에 정보를 표시할 수도 있습니다.

따라서 코드와 정적 데이터를 메모리에 로드하고, 스택을 생성 및 초기화하고, I/O 작업 수행과 관련된 기타 작업을 수행함으로써 OS는 프로세스를 실행할 단계를 준비합니다. 마지막으로 마지막 작업이 하나 남았습니다. main() 함수라고 하는 진입점을 통해 프로그램을 실행하는 것입니다. main() 함수를 실행하면 OS는 새로 생성된 프로세스에 CPU 제어권을 넘겨주고 프로그램이 실행되기 시작합니다.

프로세스 상태

이제 프로세스가 무엇인지, 프로세스가 어떻게 생성되는지 어느 정도 이해했으므로 프로세스 상태를 나열해 보겠습니다. 가장 간단한 형태로 프로세스는 다음 상태 중 하나일 수 있습니다.
● 달리는. 실행 시 프로세스는 프로세서에서 실행됩니다. 이는 명령이 실행되고 있음을 의미합니다.
● 준비. 준비 상태에서는 프로세스를 실행할 준비가 되었지만 어떤 이유로 OS가 지정된 시간에 프로세스를 실행하지 않습니다.
● 막힌. 차단된 상태에서 프로세스는 일부 이벤트가 발생할 때까지 실행 준비가 되지 않도록 하는 일부 작업을 수행합니다. 한 가지 일반적인 예는 프로세스가 IO 작업을 시작할 때 다른 프로세스가 프로세서를 사용할 수 있도록 차단되는 것입니다.

이러한 상태를 그래프 형태로 상상할 수 있습니다. 그림에서 볼 수 있듯이 프로세스 상태는 OS의 재량에 따라 RUNNING과 READY 사이에서 변경될 수 있습니다. 프로세스 상태가 READY에서 RUNNING으로 변경되면 해당 프로세스가 예약되었음을 의미합니다. 반대 방향 - 레이아웃에서 제거되었습니다. 예를 들어 IO 작업을 시작하는 등 프로세스가 BLOCKED되는 순간 OS는 IO 완료와 같은 일부 이벤트가 발생할 때까지 이 상태를 유지합니다. 이 순간 READY 상태로 전환되고, OS가 결정하면 즉시 RUNNING 상태로 전환될 수도 있습니다.
두 프로세스가 이러한 상태를 어떻게 이동하는지에 대한 예를 살펴보겠습니다. 우선 두 프로세스가 모두 실행 중이고 각각 ​​CPU만 사용하고 있다고 가정해 보겠습니다. 이 경우 상태는 다음과 같습니다.

다음 예에서 첫 번째 프로세스는 일정 시간 실행된 후 IO를 요청하고 BLOCKED 상태에 들어가 다른 프로세스가 실행되도록 허용합니다(그림 1.4). OS는 프로세스 0이 CPU를 사용하지 않는 것을 확인하고 프로세스 1을 시작합니다. 프로세스 1이 실행되는 동안 IO가 완료되고 프로세스 0의 상태가 READY로 변경됩니다. 마지막으로 프로세스 1이 완료되고, 완료되면 프로세스 0이 작업을 시작하고 실행하고 완료합니다.

데이터 구조

OS 자체는 프로그램이며 다른 프로그램과 마찬가지로 다양한 관련 정보를 추적하는 몇 가지 주요 데이터 구조를 가지고 있습니다. 각 프로세스의 상태를 추적하기 위해 OS는 일부 프로세스를 지원합니다. 프로세스 목록 READY 상태의 모든 프로세스에 대한 정보와 현재 실행 중인 프로세스를 추적하기 위한 몇 가지 추가 정보입니다. 또한 OS는 차단된 프로세스를 모니터링해야 합니다. IO가 완료된 후 OS는 필요한 프로세스를 깨우고 실행할 준비가 된 상태로 놓아야 합니다.

예를 들어 OS는 프로세서 레지스터의 상태를 보존해야 합니다. 프로세스가 중지되는 순간 레지스터의 상태는 프로세스의 주소 공간에 저장되며, 동작이 계속되는 순간 레지스터의 값이 복원되어 이 프로세스의 실행이 계속됩니다.

준비됨, 차단됨, 실행 중 상태 외에도 몇 가지 다른 상태가 있습니다. 때로는 생성 당시 프로세스가 INIT 상태일 수 있습니다. 마지막으로, 프로세스가 이미 완료되었지만 해당 정보가 아직 지워지지 않은 경우 프로세스가 FINAL 상태에 놓일 수 있습니다. UNIX 시스템에서는 이 상태를 다음과 같이 부릅니다. 좀비 프로세스. 이 상태는 상위 프로세스가 하위 프로세스의 반환 코드를 알고 싶어하는 경우에 유용합니다. 예를 들어 일반적으로 0은 성공을 나타내고 1은 오류를 나타내지만 프로그래머는 다른 문제를 알리기 위해 추가 출력 코드를 발행할 수 있습니다. 상위 프로세스가 종료되면 wait()와 같은 최종 시스템 호출을 통해 하위 프로세스가 종료될 때까지 기다리고 종료된 프로세스와 관련된 모든 데이터를 지울 수 있음을 OS에 알립니다.

강의의 핵심 포인트:

● Процесс — OS에서 실행 중인 프로그램의 주요 추상화입니다. 언제든지 프로세스는 해당 상태, 즉 주소 공간의 메모리 내용, 명령어 포인터 및 스택 포인터를 포함한 프로세서 레지스터의 내용, 읽거나 쓰는 열린 파일과 같은 IO 정보로 설명할 수 있습니다.
● 프로세스 API 프로그램이 프로세스를 호출할 수 있는 호출로 구성됩니다. 일반적으로 이러한 호출은 생성, 삭제 또는 기타 호출입니다.
● 프로세스는 실행 중, 준비 완료, 차단됨 등 여러 상태 중 하나에 있습니다. 스케줄링, 스케줄링 예외 또는 대기와 같은 다양한 이벤트로 인해 프로세스 상태가 서로 바뀔 수 있습니다.
● 프로세스 목록 시스템의 모든 프로세스에 대한 정보를 포함합니다. 각 항목을 프로세스 제어 블록이라고 하며 실제로는 특정 프로세스에 대해 필요한 모든 정보를 포함하는 구조입니다. 

출처 : habr.com