협업 스케줄링이 I / O 조작을 수행 할 때 프로세스를 일시 중단합니까?

19

많은 운영 체제 참조에 따르면 (선점 형이 아닌) 협력적인 멀티 태스킹을 사용하면 프로세스가 CPU를 명시 적으로 자발적으로 일시 중단 할 때까지 유지합니다. 실행중인 프로세스가 즉시 만족할 수없는 I / O 요청을 수행하는 경우 (예 : 아직 사용할 수없는 키 입력을 요청하는 경우) 스케줄러가 일시 중단하거나 요청을 처리 할 수있을 때까지 실제로 CPU를 유지합니까?

[ "i / o의 블록"을 "즉시 충족 할 수없는 I / O 요청을 수행함"으로 대체하도록 편집되었습니다.]

operating-systems process-scheduling

— 엘렌 스퍼터 스
소스

이 질문은 imho가 여기서 다루지 않는 운영 체제의 특정 사항을 요구하는 것 같습니다. 그렇지 않은 경우 질문을 더 추상적 인 질문으로 바꾸십시오.

— Raphael

3

유닉스 그룹에 게시했을 때 하나의 특정 운영 체제가 아니기 때문에 여기에 부적절하고 여기에 속해 있다고 들었습니다. 나는 이것이 분기 예측에 관한 질문과 비슷하다고 생각합니다. 커뮤니티가 여기에서 무엇이 적절하고 부적절한 지 결정하는 것이 흥미로울 것입니다.

— Ellen Spertus

15

진정한 "협업"환경에서 하드웨어 보호가 없다면 프로세스는 I / O를 확실히 차단하고 I / O가 완료 될 때까지 제어를 포기하지 않을 수 있습니다 (또는 전혀 제어를 포기하지 않습니다). 예를 들어, Windows 3.1은 이런 식입니다. 단일 사용자 프로세스가 전체 컴퓨터를 인수하고 다른 컴퓨터가 실행되지 못하게하려는 경우 가능합니다.

그러나 멀티 태스킹이있는 시스템에서는 시스템 API I / O 명령이 호출 될 때 프로세서에 대한 제어권을 포기할 것으로 예상합니다. 따라서 프로세스가 일반 시스템 API를 사용한다고 가정 할 때 I / O에서 실행중인 프로세스가 차단되면 I / O가 완료 될 때까지 다른 프로세스를 실행할 수 있으며 결국 I / O가 완료되면 원래 프로세스가 재개됩니다. . 다시 말해, 차단 I / O 기능을 호출하는 것은 협력 시스템의 프로세스가 자발적으로 일시 중단 할 수있는 한 가지 방법입니다.

— 칼 머 머트
소스

11

실행중인 프로세스가 I / O에서 차단되는 경우

IO 차단은 프로세스를 중단하는 것과 거의 같습니다. 리눅스 커널의 문맥, 일부 IO 시스템 호출을 실행에 같은 read()원인이됩니다 sysenter호출, 그 IO 돌봐 트리거 또는 인터럽트 핸들러를 do_sys_read()궁극적으로. 여기서 현재 요청을 즉시 만족시킬 수 없으면 함수가 호출 sched()되어 다른 프로세스를 실행할 수 있습니다.

협력 시스템의 맥락에서, 당신이 IO를 이유로 시스템 호출을 할 때, 요청을 충족시킬 수 없다면 커널은 다른 작업을 선택하고 실행합니다. 이 문서 는 몇 가지 배경 지식을 제공합니다. 기본적으로 IO를 기다렸다면 해당 IO를 영원히 기다리게됩니다. 협동 스케줄링의 아이디어는 sched()CPU를 많이 사용하는 작업을 수행하는 경우 자주 호출 하거나 동등한 CPU 양도 방법입니다.

커널 모드 고려 사항이 더 흥미로워집니다. 특정 임베디드 플랫폼 과 같이 사용 가능한 아키텍처에서 인터럽트 핸들러는 하드웨어 또는 소프트웨어 인터럽트에 대한 응답으로 여전히 호출됩니다. 일반적으로 구현 측면에서 인터럽트 처리 를 비활성화하는 것이 가능 하지만 단점도 있습니다.

4

협업 스케줄링 (바람직하게는 cooperative multitasking) 모델에서는 운영 체제가 프로세스 실행 시간을 제어 할 수 없다는 의미에서 스케줄러 개념이 없습니다.

올바르게 프로그래밍 된 응용 프로그램은 자발적으로 I / O의 CPU를 포기합니다. 그러나 잘못 작성된 응용 프로그램은 I / O를 계속 대기하여 다른 프로세스를 차단할 수 있습니다.

추신 :이 접근법은 나중에 외부 스케줄러가있는 선점 예약을 선호하여 대부분의 OS에서 포기했으며 이제는 다른 OS에서 사용되는 모든 종류의 다른 스케줄링 알고리즘이 있습니다.

편집 : 내 대답은 원래 형식 (년 전 : P)으로 설명 된 일정을 기반으로했습니다. Gilles는 일부 시스템은 여전히 협력 스케줄링을 사용한다고 언급했습니다. 그리고 스케줄러가 있습니다. 해당 시스템이 COS를 순수하고 원래 형태로 사용하는지 잘 모르겠습니다.

— 안킷
소스

2

RTOS를 포함하여 (이에 국한되지는 않음) 많은 임베디드 OS에는 협업 스케줄링이 있습니다. 스케줄러가 없다고 말하는 것은 아닙니다. 스케줄러는 다음에 실행할 스레드를 결정하는 코드입니다. 선점은 실행중인 작업 요청과 달리 스케줄러가 자동으로 입력되는 것입니다.

— Gilles 'SO- 악마 중지'

@Gilles 좋은 의견 (편집에 넣음). 나는 완전히 사용되지 않은 것에 동의합니다. 내 대답은 원래 정의 된 알고리즘을 기반으로했습니다. AFIK, 일부 수정 (일부 스케줄러 사용)과 함께 사용됩니다. 일부 OS에서 순수한 형태로 사용되었는지 확실하지 않습니다.

— Ankit

4

협동 멀티 태스킹은 실행중인 컨텍스트가 스케줄러에 대한 제어를 명시 적으로 포기해야하며 원하는 경우 컨텍스트 전환이 발생하지 않도록 할 수 있습니다.

대부분의 구현은 프로세서 할당의 공정성을 높이기 위해 신속하게 반환되지 않는 시스템 호출에 대해 컨텍스트 전환을 명시 적으로 수행합니다.

일반적으로 실패한 프로세스 (또는 나머지 시스템에 의도적으로 서비스를 거부)가 자주 작업 전환을 방지 할 수 있습니다.

Gilles가 설명하는 선점은 활성 작업 및 강제 컨텍스트 전환의 시간적 중단을 방지하는 시스템 아키텍처의 한계입니다.

— 페카
소스