Nun schauen wir noch einmal auf Programme. Ein Programm als gerichteter Ablauf eines Geschehens.

Betriebssysteme bringen Programme zur Ausführung, indem sie dazu einfachen Prozess jeweils erzeugen.

Der Prozess wird dann bereitgestellt und normalerweise begleitet ein Betriebssystem

so ein Prozess auch während seiner Lebenszeit, also während das Programm

läuft. Im Informatikkontext ist so ein Prozess ohne Programm nicht möglich.

Im Programm ist die Berechnungsvorschrift für diesen Prozess kodiert. Er definiert

diese Vorschrift, definiert diesen Prozess. Das Programm legt damit diesen

Prozess fest, gibt ihn vor und hin und wieder sind in diesem in diesem Programm

eben auch Anweisungen kodiert, die dazu führen, andere Prozesse zu erzeugen,

diese dann zu steuern und möglicherweise eben auch zu terminieren.

Vorausgesetzt der Prozessor bietet die nötigen Befehle an, wenn wir uns auf der

Maschinenprogramm-Ebene befinden und von Prozessen ausgehen, die durch das

Betriebssystem selbst verwaltet werden, dann sind es hier typischerweise

Betriebssystembefehle, die aktiviert werden müssten, um Prozesse zu

möglichen, zu steuern und zu terminieren. So ein Programm selbst beschreibt dann

die Art des Ablaufs eines Prozesses. Dieser Ablauf kann nämlich sequenziell

oder parallel sein. Wir sprechen von sequenziellen Programmen oder eben auch

von sequenziellen Prozessen, wenn in dem Programm praktisch sichergestellt ist,

dass keine Folge von zeitlich sich überlappenden Aktionen entstehen kann.

Also man sagen kann, dass eben dieses Programm nachher deterministisch

abläuft und demzufolge das Berechnungsergebnis determiniert ist.

Ist dies nicht der Fall? Können die Aktionen in diesem Programmablauf nachher

überlappen, dann haben wir ein nicht sequenzielles Programm. Wir haben einen

nicht sequenziellen Prozess vorzulegen und das bedeutet, wir haben parallelen

Prozess, wir haben ein paralleles Programm. In beiden Arten wird so ein

Programmablauf eben aus solchen Aktionen bestehen. Einmal im

sequenziellen Fall werden diese Aktionen strikt sequenziell hintereinander

wohldefiniert stattfinden und im parallelen Fall können sich diese

Aktionen tatsächlich überlappen. Je nach zugrunde liegende

Ausführungsplattform könnten diese Aktionen sehr gleichzeitig stattfinden.

Hierbei ist eben insbesondere zu beachten, dass ein Programmablauf auf

einer Abstraktionsebene sequenziell verlaufen kann, auf einer anderen, nämlich

auf einer tieferen, letztendlich aber möglicherweise parallel zustande kommt.

Das wollen wir uns noch mal ein bisschen genauer anschauen.

Wenn wir uns so ein Programm als Begriff noch mal ein bisschen verdeutlichen,

also letztendlich die konkretisierte Form eines Algorithmes ist und mit der

Vorstellung, dass eben in dem Programm oder durch so ein Programm eben ein oder

mehrere Prozesse formuliert werden. Hier hätten wir den Prozess des

Inkrementierungsvorgangs beschrieben auf der Hochsprachenebene für eine virtuelle

Maschine C, ein C-Unterprogramm, was einfach letztendlich einen 64-Bit-Wert

inkrementieren soll. Der Inkrementierungsvorgang auf einer tieferen Ebene

kann sich aber auch wie folgt darstellen, wo wir jetzt hier auf der

Assembliersprachenebene offensichtlich drei verschiedene Befehle haben, die in

Folge ablaufen müssen, um letztendlich diesen Inkrementierungsvorgang, den wir

gerade gesehen haben, bewerkstelligen zu können. Und wenn wir uns das jetzt mal

vergleichend anschauen, dann sehen wir eben auf der Hochsprachenebene eigentlich

eine Aktion für diese Inkrementierung, wohingegen wir auf der

näst tieferen Ebene der Assembliersprachenebene wir im Wesentlichen drei Aktionen sehen,

die letztendlich denselben Inkrementierungsvorgang nur auf

unterschiedlichen Ebenen, auf unterschiedlichen Maschinenebenen, wenn