Re: Prozedur und Prozess - Unterschied? Philosophen mit RMI
- From: Jochen Theodorou <blackdrag@xxxxxx>
- Date: Mon, 03 Dec 2007 17:24:48 +0100
Gerhard Wegel schrieb:
On Thu, 29 Nov 2007 12:12:16 +0100, Jochen Theodorou
<blackdrag@xxxxxx> wrote:
erstmal sorry für die späte Antwort..
hi,das ist aber sehr fürsorglich ;-)
da ich mal nicht ganz den AHA-effekt zerstören möchte antwrote ich nicht direkt,
sondern versuche deine Gedanken ein bischen zu leiten ;)So etwas ähnliches hat mir ein Prof. auch schon mal gesagt: "lesen Sie
mein Buch!"
Na gut, Spass beiseite. Ich will mich mal leiten lassen, habe aber
ehrlich gesagt noch nicht das Gefühl als würde der Aha-Effekt hinter
der nächsten Ecke lauern.
Der Aha-Effekt ist manchmal dass die Dinge tatsächlich so einfach sind wie du vermutest ;) Ich glaube im Grunde ging es deinem Professor um eine Verständnisfrage im Stiel von "Was ist die Beziehung von Syntax und Semantik". Je nach Sichtweise ließe sich da durchaus eine etwas längere Antwort geben, aber im Prinzip will man nur wissen dass die Syntax die Form und die Semantik die Bedeutung festlegt. Wenn man jetzt mit Psychologie und ähnlichen kommt, dann kann der Zusammenhang zwischen Syntax und Semantik von zum beispiel einer Programmiersprache ganz andere Dimensionen annehmen. Ist halt ein völlig anderer Aspekt.
Ich habe immer gelernt das eine Prozedur ein Unterprogramm ist und das ein Programm ein Folge von Anweisungen ist. Und ich habe gelernt das ein Prozess ein laufendes Programm beschreibt. Ein Thread wäre dann ein Teil eines Prozesses und beschreibt nebenläufige Programmausführung und ein paar weitere Dinge. So könnte man grob sagen dass ein Thread ein Prozess in einem Prozess ist und dann kommt man leicht zu
"""
Der Prozess ist die Umgebung in der ein oder mehrere Threads laufen.
"""
Aber prinzipiell ist deine Vermutung:
[...]
Die Prozedur ist das statische Programm (Rezept) an sich, also "tote
Worte auf Papier". Wenn aber der Programmcode also die Prozedur auf
einer Maschine ausgeführt wird, dann ist das ein Prozess (der Vorgang
der Ausführung). Also der Prozess ist die inkarnation der Prozedur.
schonmal nicht schlecht. Ich würde vielleicht statisch weglassen.
Damit ist der Prozess aber immer noch (im prinzip) Programmcode,
genauso wie die Prozedur, nur eben in Ausführung.
Was aber ein wichtiger Unterschied ist.
Der Prozess hat aber zusätzlich noch Ressourcen auf der Maschiene, CPU
Speicher, Stack usw. zur Verfügung - eben alles was er für die
Ausführung braucht.
ein Prozess ist auch Zeitabhängig, denn der Prozess ist in der Regel nicht zu jedem Zeitpunkt in der selben Stelle im Programm, zumindest wenn kein Deadlock oder sowas vorliegt ;) Aber ich denke Tannenbaum interessiert sich immer sehr für die Ressourcen des Betriebssystems ;)
Dann kommen noch die Threads hinzu. Ein Thread ist im Prinzip auch nur
Programmcode dem der Sheduler ab und zu Leben einhaucht. Der Prozess
ist im Prinzip ein fauler Hund. Anstatt den Programmcode selber
auszuführen, gibt er diese Aufgabe an den oder die Threads weiter.
So würde ich das nicht sehen. Der Scheduler ist zum Beispiel ein Problem.. Es gibt unterschiedliche Arten von Threads, manche werden vom BS gesteuert, andere vom Prozess selbst. Entsprechend kann es auch sein, dass der Prozess für die Kommunikation zwischen den Threads zuständig ist. Aus Sicht des eines BS das Threads unterstützt Ist ein Prozess denke ich erstmal auch eine Art Thread, welcher vielleicht neue Threads "beantragen wird". Außerdem ist der Thread Teil des Prozess.. ich glaube in den wenigsten BS kann man einen Thread killen, nur den Prozess und damit alle Threads, die zu diesem Prozess gehören. Irgendwo meine ich auch mal einen Vergleich gesehen zu haben der Threads mit Unterprozessen mit shared Memory gleichgestellt hat. Naja, stimmt vielleicht unter bestimmten Umständen, aber allgemein finde ich das zu spezifisch.
Die
machen die Arbeit und der Prozess gibt die Arbeitsergebnisse der
Threads als Rückgabewert an den Aufrufer zurück. Die Delegierung der
Programmausführung an die Threads macht eben dann Sinn wenn innerhalb
des Prozesses Aufgaben paralell laufen sollen.
ja
Der Prozess kann nicht paralell zu sich selbst laufen. Das machen die> Threads auch wunderbar.
ich kann eventuell einen gleichartigen Prozess parallel starten, aber das ist nicht der gleiche... allerdings trifft das auch auf Threads zu. diese beiden Sätze würde ich also an deiner Stelle nochmal überdenken... oder ich interpretiere zu sich selbst einfach falsch ;)
[...]
Es ist und bleibt Programmcode - die Abstraktion ändert sich. Wo soll
da eine Beziehung sein?.
Nicht die Abstraktion. Für mich ist eine Abstraktion eine Art Verallgemeinerung und ich sehe da keine. Nochmal, das Programm bestimmt wie sich der Prozess verhält, der Prozess ist das konkrete ablaufen des Programms. Das ist für mich eine Beziehung.
Mal ist der code statisch auf Papier
bzw. in Maschinencode ;)
und mal ist er dynamisch in Ausführung.
ja, und diese Ausführung ist vom Code abhängig, aber auch von den Ressourcen deines BS! Letzteres ist durchaus wichtig. Es muss auch nicht unbedingt nur das BS sein, es kann auch zum Beispiel ein Server im Internet sein oder der Benutzer vor der Kiste. Das Programm ändert sich durch solche Dinge (normalerweise) nicht, wohl aber der Prozess der damit interagiert.
Die Prozedur ist das Rezept, der
Prozess ist die Küche (Laufzeitumgebung) und der Thread ist der Koch,
der das Rezept innerhalb der Küche umsetzt.
Es tut mir leid, aber ich hab immer noch keine Ahnung worauf die Frage
nach einer Beziehung zwischen Prozedur und Prozess abzielt.
Ich denke wirklich eine ganz einfach Frage des Verständnisses. Die Sache wird wesentlich witziger wenn du an RMI denkst. eigentlich meine ich wohl eher RPC, aber auf jeden Fall das Aufrufen einer Prozedur außerhalb deines Prozesses (eventuell auf einem anderen Rechner).
Während zuvor das komplette Programm dem Prozess vorlag gibt es nun Teile die in einem anderen Prozess enthalten sind. Damit wird der einfach Unterprogrammaufruf, der zuvor höchst wahrscheinlich ein einfacher Sprung war nun zu einer Kommunikation zwischen zwei Prozessen unter Nutzung von zusätzlichen Ressourcen des Betriebssystems. Entsprechend gilt dass dann auch für Threads. Die einfache Beziehung von Programm und Prozess von zuvor wird also wesentlich komplizierter. Als Ergebnis erhalte ich im Prinzip zwei Programme, die nun über eine Schnittstelle zueinander verfügen, wie zum Beispiel RMI.
Zuvor hatte ich: "ich schreibe ein Programm und mein Prozess führt das Programm aus", jetzt habe ich: "ich schreibe ein Programm, teile dies in mehrere Teile, wobei diese Teile untereinander über das BS kommunizieren und habe mehrere Prozesse, die diese neuen Programme ausführen"
Während man bei nebenläufigen Threads der Prozess noch einen eigenen Scheduler haben könnte (in Java nicht wirklich machbar) muss man bei RMI damit rechnen dass der andere Prozess vielleicht nicht mal auf der selben Maschine und unter einem anderen BS läuft... was sich auch entsprechend auf die Ressourcen auswirkt.
Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
.
- Prev by Date: Re: Prozedur und Prozess - Unterschied? Philosophen mit RMI
- Next by Date: Re: Prozedur und Prozess - Unterschied? Philosophen mit RMI
- Previous by thread: Re: Prozedur und Prozess - Unterschied? Philosophen mit RMI
- Next by thread: Re: Prozedur und Prozess - Unterschied? Philosophen mit RMI
- Index(es):
Relevant Pages
|
Loading
