# 5-Zustands-Prozessmodell

a)
	i) Übergang von *blocked* zu *running* wird nur via *ready* realisiert, da der Scheduler bereits periodisch Prozesse aus *ready* aufweckt.
		Zusätzlich auch noch den jeweiligen Prozess aufzuwecken wäre schlicht unnötig.
	ii) Fordert ein Prozess E/A-Resourcen an, so wird er nach *blocked* verschoben bis die jeweilige E/A-Operation per Unterbrechung bekannt macht, dass der Vorgang abgeschlossen ist.
	iii) Ein Prozess, der nicht läuft, kann keine E/A-Resource anfordern.	
b)
	(i) *new* → *ready*
		~ Ein Nutzer hat seine Shell angewiesen `Hello World!` auszugeben, diese forkt um später `/bin/echo` aufzurufen.
			
		*ready* → *running*
		~ Der Shell-Prozess ruft `wait` auf den soeben gespawnten Prozess auf und wird daher *blocked*.
		Der Scheduler entscheidet nun zum Kindprozess zu wechseln.

	    *running* → *ready*
		~ `/bin/echo` hat nicht innerhalb der switching-Frequenz des Schedulers terminiert.
		Der Scheduler verschiebt `/bin/echo` in *ready* und wechselt zu einem anderen Prozess.

		*running* → *blocked*
		~ `/bin/echo` ist dynamisch gelinkt und möchte eine library von der Festplatte lesen.
		Es setzt einen Syscall ab und wartet auf das Ergebnis.

	    *blocked* → *ready*
		~ Die Festplatte fängt an einen Stream von bytes zu schicken.
		Der Scheduler fängt die Unterbrechung ab und verschiebt `/bin/echo` nach *ready*

	    *running* → *exit*
	    ~ `/bin/echo` terminiert.
	(ii) *new*. Prozesse werden im reinen batch-betrieb nicht dynamisch erzeugt.

# Prozesse

a) Kontext
b) Uniprogramming
c) 13.3 min
d) `fork`
e) Scheduler