시스템 프로세스와 사용자 프로세스, 커널 제어 경로, 커널 스레드의 차이점

Q: 사용자 프로세스와 커널 프로세스는 모두 커널이 아닌 프로세스인가요?

정답이 있을지는 모르겠지만 한번 시도해보겠습니다.
"운영 체제 설계 및 구현"(A. Tanenbaum) 제3판 2.1장에서 인용하면 다음과 같습니다.

2.1.프로세스 소개

모든 최신 컴퓨터는 동시에 여러 가지 작업을 수행할 수 있습니다. 사용자 프로그램을 실행하는 동안 컴퓨터는 디스크에서 데이터를 읽고 텍스트를 화면이나 프린터로 출력할 수도 있습니다. 다중 프로그래밍 시스템에서 CPU는 또한 한 프로그램에서 다른 프로그램으로 전환하며, 각 프로그램은 수십 또는 수백 밀리초 동안 실행됩니다. 엄밀히 말하면 CPU는 한 번에 하나의 프로그램만 실행하지만 1초 내에 여러 프로그램을 동시에 실행할 수 있어 사용자에게 병렬성이라는 환상을 줄 수 있습니다. 때때로 사람들은 다중 프로세서 시스템(동일한 물리적 메모리를 공유하는 두 개 이상의 CPU를 가짐)의 실제 하드웨어 병렬성과 대조하기 위해 의사 병렬성에 대해 이야기합니다. 여러 병렬 활동을 추적하는 것은 어렵습니다. 따라서 운영 체제 설계자들은 수년에 걸쳐 병렬 처리를 더 쉽게 처리할 수 있는 개념 모델(순차 프로세스)을 개발해 왔습니다. 모델, 그 용도 및 그 결과 중 일부가 이 장의 주제를 구성합니다.

2.1.1. 프로세스 모델

이 모델에서는 컴퓨터에서 실행 가능한 모든 소프트웨어(때때로 운영 체제 포함)가 여러 순차 프로세스 또는 단순한 프로세스로 구성됩니다.프로세스는 프로그램 카운터, 레지스터 및 변수의 현재 값을 포함하는 단순한 실행 프로그램입니다.

(강조는 내 것)

아직 책을 읽을 시간은 없었지만 이 설명에 따르면 "프로세스"는 프로세서에서 실행되는 작업 단위이며 필요한 모든 리소스(이미지, 상태, 레지스터, 카운터...)를 가지고 있습니다. .

수정된 질문에 대한 답변

커널은 항상 커널 모드에서 실행되며 커널 공간만 사용합니다.

이는 코어 유형에 따라 다릅니다. 모놀리식 커널은 단일 주소 공간(커널 공간)에서 콘텐츠를 실행하는 반면, 마이크로커널은 사용자 공간에서 커널 프로세스를 실행할 수 있습니다.

두 책에 언급된 "시스템 프로세스"가 사용자 공간, 커널 공간 또는 둘 다에서 실행될 수 있습니까?

위에서 언급한 것처럼 시스템 프로세스는 커널 유형에 따라 두 가지 모드로 실행될 수 있습니다.

사용자 프로세스와 시스템 프로세스는 모두 커널 프로세스가 아닌 프로세스입니까?

예, 사용자 프로세스와 시스템 프로세스는 모두 프로세스이므로 이름이 지정되었습니다. ;-) 그러나 쉼표 뒤의 부분을 이해하지 못합니다.

"시스템 프로세스"는 커널 제어 경로 및 커널 스레드와 다릅니까?

예. 프로세스(사용자 또는 시스템 = 커널)가 다릅니다.

커널 제어 경로는 일련의 명령을 나타내며, 커널 스레드(일명 LWP - 경량 프로세스)는 스레드 라이브러리에서 생성된 사용자 스레드와 달리 커널에서 직접 생성 및 예약된 스레드입니다.

결론적으로

ㅏ프로세스단지 이론적인 구성일 뿐입니다.
ㅏ핵심예를 들어 프로세스 개념을 구현하는 운영 체제의 일부입니다. 해당 프로세스의 일정을 계획합니다.
ㅏ철사독립적으로 예약할 수 있는 프로세스의 가장 작은 부분입니다.

Linux의 경우 작업(스레드의 커널 내부 개념; 스레드는 메모리 및 열린 파일과 같은 리소스를 공유할 수 있으며 일부는 커널 내에서만 실행됨)이 사용자 모드에서 실행될 수 있거나 (실행 스레드) 시스템 호출을 수행하기 위해 커널(및 그 이상)로 전송됩니다. 사용자 스레드는 인터럽트를 수행하기 위해 일시적으로 하이재킹될 수 있습니다(그러나 이는 실제 실행 스레드가 아닙니다).

프로세스가 "시스템 프로세스"인지 일반 사용자 프로세스인지 여부는 Unix에서는 전혀 관련이 없으며 동일한 방식으로 처리됩니다. Linux에서는 일부 작업이 커널에서 실행되어 기타 작업을 처리합니다. 그러나 이는 "시스템 프로세스"가 아닌 커널 작업입니다.

한 가지 중요한 경고:복잡한 소프트웨어 제품(컴파일러 및 운영 체제는 특히 터무니없는 예임)에 대한 교과서는 간단한 알고리즘(종종 반세기 동안 심각하게 사용되지 않은 알고리즘)을 설명하는 경향이 있습니다.많은체계적이고 간단한 방식으로 설명할 수 있는 방식으로 처리하기에는 너무 복잡합니다. 컴파일러의 대부분은 임시 조정입니다(특히 변환이 대부분 실제 사용에서 발생하는 가능성의 하위 집합인 코드 최적화 영역에서). Linux의 경우 대부분의 코드는 장치 드라이버(운영 체제 텍스트에서 장치 관련이라고 언급됨)이며, 이 코드의 상당 부분은 자체 사양을 따르지 않는 오작동하는 장치를 처리하는 데 사용됩니다. 또는 "동일 장치"의 버전에 따라 동작이 다릅니다. 설명된 세부 사항은 해결해야 할 작업의 일부일 뿐인 경우가 많습니다.할 수 있는몇 가지 좋은 이론으로 단순화되었으며 지저분하고 불규칙한 부분은 (거의) 완전히 제외되었습니다. 예를 들어 Cris Fraser와 David Hanson은 그들의 책에서 다음과 같이 설명합니다.저가항공사컴파일러 문 일반적인 컴파일러 텍스트에는 주로 어휘 분석 및 구문 분석에 대한 설명이 포함되어 있으며 코드 생성에 대한 설명은 거의 없습니다. 이러한 작업은 컴파일러 코드의 약 5%를 차지하며(단순하게 설계되었습니다!) 오류율은 무시할 수 있습니다. 컴파일러의 복잡한 부분은 표준 텍스트에서 다루지 않습니다.

여기에 짧지만 명확한 답변을 드리고자 합니다. 최신 Linux 커널에서만 작동합니다.

struct task커널에서 내부적으로 가장 작은 예약 가능한 단위로 사용되는 s가 있습니다 . 이는 항상 ring0을 사용하여 커널 코드에 의해 생성되고 ring0에서 실행을 시작하지만 나중에 ring3으로 전환하거나 링0으로 다시 전환할 수도 있고 그렇지 않을 수도 있습니다(플랫폼별 사용) 시스템 호출 명령)) 이후.

작업에는 많은 리소스나 속성이 있으며, 그 중 가장 중요한 것은 메모리 공간, 작업 ID(최상위 pid 네임스페이스에서 본 tid) 및 작업 그룹 id(최상위 네임스페이스에서 본 pid)입니다. ring3에서는 작업이 struct task자신의 작업에 직접 액세스할 수 없지만 적어도 방금 언급한 속성은 /proc커널에 의해 fs를 통해 ring3에 노출됩니다. 그러나 최신 Kenerl은 /proc/[pid]/statusprocfs 인스턴스와 연관된 pid 네임스페이스에서 표시된 작업 ID를 참조하기 위해 "Pid"라는 단어를 사용하는 등 이상한 방식으로 이를 노출할 수 있습니다 .

작업은 동일한 메모리 공간을 공유하거나 동일한 작업 그룹 ID를 가질 수 있는 것처럼 이러한 속성(최상위 pid 네임스페이스에서 볼 때 tid 제외)을 다른 작업과 공유할 수도 있고 공유하지 않을 수도 있습니다.

이제 링3, 즉 사용자 공간의 사용자는 "스레드"와 "프로세스"의 개념을 고안할 수 있습니다. 그러나 이는 순전히 사용자 공간의 발명품이기 때문에 다른 사람/교과서에서는 다른 용어를 사용할 수 있습니다. 그래서 여기서는 일반적으로 사용되는 용어에 대해서만 이야기하겠습니다.

OS-Thread(스레드): 작업의 동의어입니다.

커널 스레드: 링3으로 전환하지 않고 항상 커널과 메모리 공간을 공유하는 작업입니다.

OS-Process: 커널은 프로세스의 존재를 추적하지 않으며, 인간은 이를 동일한 작업 그룹 ID(최상위 pid 네임스페이스에서 볼 때 pid)를 가진 하나 이상의 작업으로 정의합니다. 이 스레드가 모두 죽으면 인간의 두뇌에서 프로세스가 손실됩니다.

중요한 흥미로운 사실은 운영 체제 프로세스에 하나 이상의 운영 체제 스레드가 포함될 수 있다는 결론을 내릴 수 있다는 것입니다. 운영 체제 프로세스의 작업은 실제로 커널의 스레드에 의해 제한됩니다. 실행할 수 있는 항목에 관한 속성입니다.연합 국가공유하다.

작업이 생성되면 특정 프로세스에 속하며 이 관계는 종료될 때까지 절대 변경되지 않습니다.

프로세스에 속한 작업은 정확히 동일한 메모리 공간을 공유해야 합니다.

프로세스에 속한 작업은 다른 사용자 네임스페이스나 pid 네임스페이스에 있을 수 없으며 공유되어야 합니다.

질문: Maurer의 책과 Bovet의 책에 나오는 "시스템 프로세스"는 동일한 개념인가요?

Maurer가 사용하는 것을 보았습니다.시스템 프로세스두 가지 모두를 포괄하는 일반적인 용어로사용자 프로세스그리고커널 스레드.

내가 아는 한 Bovet은 다음을 사용하지 않습니다.시스템 프로세스Maurer보다 더 구체적인 개념을 정의하십시오. 그러나 그는 덜 엄격한 언어를 사용했을 수도 있습니다. 그래서 나는 그것들을 직접적으로 동일시하지 않도록 조심할 것입니다. 이 문장이 어렵네요

일부 시스템 프로세스는 커널 모드에서만 실행되기 때문에 최신 운영 체제는 해당 기능을 불필요한 사용자 모드 컨텍스트로 인해 방해받지 않는 커널 스레드에 위임합니다.

누구의 기능이 누구에게 위임됩니까? 운영 체제의 기능입니까, 아니면 시스템 프로세스의 기능입니까? 시스템 프로세스가 커널 모드에서만 실행되기 때문에 해당 기능이 커널 스레드에 위임된다고 말하는 것은 의미가 없습니다. 운영 체제가 특정 운영 체제 기능을 커널 스레드에 "위임"한다고 생각하는 것이 합리적입니다. 그러나 Maurers의 정의를 사용하면 "왜냐하면"은 실제로 의미가 없습니다.시스템 프로세스. 그러므로 나는 이 문장이 어떤 엄밀한 의미를 갖는다고 생각하지 않는다.

("차단"의 부족은 다소 사소한 것이며 이 세부 사항은 특정 구현과 모순될 수 있습니다).

합리적으로 느슨한 재해석은 커널이 커널 외부의 특정 "중요한 작업" 수행을 지원하지 않으며 이러한 작업 중 일부는 커널 스레드에 의해 처리된다는 것입니다.

Q. 두 책에 언급된 "시스템 프로세스"가 사용자 공간, 커널 공간 또는 둘 다에서 실행될 수 있습니까?

특정 시점에 시스템 프로세스는 사용자 공간이나 커널 공간에서 실행될 수 있습니다.

사용자 프로세스가 시스템 호출을 하면 해당 프로세스는 커널 공간에서 실행되도록 변환됩니다. 시스템 호출이 반환되면 프로세스는 다시 사용자 공간에서 실행되는 상태로 전환됩니다.

Q: "시스템 프로세스"는 커널 제어 경로 및 커널 스레드와 다릅니까?

위의 정의에 따르면 커널 스레드는 시스템 프로세스이지만 시스템 프로세스는 커널 스레드가 아닐 수도 있습니다.

Bovet은 spin_lock이 매크로가 성공하면 현재 커널 경로가 스핀 잠금(다른 커널 경로 제외)을 "획득"하게 한다고 말합니다. spin_lock커널 스레드에서 호출될 수 있으므로 커널 스레드는 커널 제어 경로로 간주됩니다. 내가 아는 한. 내가 아는 한 이것은 모순이 아니다. 그러나 커널 제어 경로가 무엇인지, 무엇이 아닌지에 대한 명시적인 정의를 찾을 수 없기 때문에 그가 해당 문구를 사용할 때마다 적용하기 위해 이 암시적 정의에 의존하지 않겠습니다.

시스템 호출, 예외 또는 인터럽트에 대한 커널 제어 경로는 커널 스레드가 아닙니다.

일부 드라이버를 제외하면 이제 스레드를 사용하여 인터럽트에 대한 거의 모든 응답을 처리합니다. (스레딩 외부의 유일한 부분은 여러 장치 간에 공유되는 인터럽트 라인을 명확하게 하는 것입니다.)

인터럽트를 스레드로 이동- LWN.net, 2008

https://www.kernel.org/doc/html/v4.20/core-api/genericirq.html("주제"를 검색하세요)