Czy harmonogramowanie kooperacyjne zawiesza procesy podczas wykonywania operacji we / wy?

Wiele odniesień do systemów operacyjnych mówi, że w przypadku wielozadaniowości kooperacyjnej (w przeciwieństwie do zapobiegawczej) proces utrzymuje procesor do momentu, aż jawnie się dobrowolnie zawiesi. Jeśli uruchomiony proces wykonuje żądanie we / wy, którego nie można natychmiast zaspokoić (np. Żąda naciśnięcia klawisza, który nie jest jeszcze dostępny), to czy program planujący zawiesza go, czy naprawdę utrzymuje procesor do czasu, aż żądanie zostanie obsłużone?

[Edytowane w celu zastąpienia „bloków we / wy” na „wykonuje żądanie we / wy, które nie może być natychmiast spełnione.”]

W prawdziwie „kooperatywnym” ustawieniu i jeśli nie ma ochrony sprzętowej, proces z pewnością mógłby zablokować I / O i nie zrzec się kontroli, dopóki I / O nie zostanie wykonane (lub w ogóle nie zrzec się kontroli). Na przykład system Windows 3.1 działał w ten sposób: jeśli proces jednego użytkownika chciał przejąć cały komputer i uniemożliwić uruchomienie czegokolwiek innego, mógł to zrobić.

Ale w systemie z wielozadaniowością oczekuje się, że systemowe polecenia interfejsu API we / wy zrzekną się kontroli nad procesorem po ich wywołaniu. Tak więc, gdy działający proces blokuje się we / wy, zakładając, że proces używa normalnych systemowych interfejsów API, inne procesy będą mogły działać do czasu zakończenia operacji we / wy, a ostatecznie oryginalny proces zostanie wznowiony po zakończeniu operacji we / wy . Innymi słowy, wywołanie blokującej funkcji We / Wy jest jednym ze sposobów, w jaki proces w systemie kooperacyjnym może się dobrowolnie zawiesić.

Jeśli działający proces blokuje się we / wy

Blokowanie we / wy jest prawie równoważne zawieszeniu procesu. W kontekście jądra Linuksa wykonanie jakiegoś wywołania systemowego IO, takiego jak read()spowoduje, że sysenterprogram obsługi lub przerwań wyzwoli opiekę nad tym IO, do_sys_read()ostatecznie dzwoniąc . Tutaj, jeśli bieżące żądanie nie może być natychmiast spełnione, wywołania funkcji, sched()które następnie mogą wykonać inny proces.

W kontekście systemu kooperacyjnego oczekiwałbym, że kiedy wykonasz wywołanie systemowe z jakiegoś powodu IO, jeśli żądanie nie może zostać spełnione, jądro wybiera inne zadanie i wykonuje je. Ten dokument stanowi pewne tło - w zasadzie, jeśli czekałeś na IO, możesz zostać zawieszony na zawsze, czekając na to IO. Ideą wspólnego planowania jest to, że często wywołujesz sched()lub równoważna metoda rezygnacji z procesora, jeśli wykonujesz zadania wymagające dużej mocy procesora.

Zagadnienia dotyczące trybu jądra stają się bardziej interesujące. W architekturach, w których są one dostępne, takich jak niektóre wbudowane platformy , programy obsługi przerwań będą nadal wywoływane w odpowiedzi na zakłócenia sprzętowe lub programowe. Zazwyczaj możliwe jest wyłączenie obsługi przerwań , ale ma to również wady.

W modelu planowania kooperacyjnego (najlepiej cooperative multitasking) nie ma koncepcji harmonogramu w tym sensie, że system operacyjny nie ma żadnej kontroli nad czasem trwania procesu.

Prawidłowo zaprogramowana aplikacja dobrowolnie zrezygnuje z procesora we / wy. Ale źle napisane aplikacje mogą po prostu czekać na operacje we / wy, blokując w ten sposób inne procesy.

PS: To podejście zostało później zrezygnowane przez większość systemu operacyjnego na rzecz planowania wyprzedzającego (który miał zewnętrzny program planujący), a teraz mamy wiele różnych algorytmów planowania używanych przez różne systemy operacyjne.

EDYCJA: Moja odpowiedź była oparta na harmonogramie, jak opisano w oryginalnej formie (lata temu: P). Jak zauważył Gilles, niektóre systemy nadal korzystają z harmonogramu kooperacyjnego. I jest harmonogram. Nie jestem pewien, czy systemy te używają COS w czystej i oryginalnej formie.

Wielozadaniowość kooperacyjna implikuje, że kontekst wykonywania musi jawnie zrzec się kontroli nad harmonogramem, a jeśli chce, może zapobiec zmianie kontekstu.

Większość implementacji wyraźnie wykonuje zmianę kontekstu dla każdego wywołania systemowego, które nie zwraca natychmiast, a często nawet jeśli tak, aby zwiększyć sprawiedliwość alokacji procesorów.

Zwykle w przypadku nieudanych procesów (lub celowo odmawiania obsługi pozostałej części systemu) możliwe jest tylko zapobieganie częstemu przełączaniu zadań.

Wykluczenie, jak wyjaśnił Gilles, jest ograniczeniem architektury systemu, które zapobiega przerwaniu w czasie aktywnego zadania i wymuszonym przełączeniom kontekstu.