2. thread

wenn ich eine methode in einem eigenen thread starte und aus dieser herraus ein andere methode aufrufe, wird diese dann im gleichen thread ausgeführt ??? o. im orginal thread wo auch der rest der classe läuft ???

Na ja die Frage stellt sich eigentlich nicht, da egal wie viel Threads du erzeugst, sie immer auf den geichen Code deiner Anwendung zugreifen. Dein Programmcode wird ja nicht geklont wenn du einen weiteren Thread erzeugst.

Um das genauer zu verstehen solltest du dir vielleicht mal genauer anschauen wie ein Betriebssystem Threads realisiert, dann würde sich deine Fage erübrigen 😉

Pass aber auf Race Conditions bei der parallelen Abarbeitung von meherern Threads auf. Also das lock Schlüsselwort für kritische Abschnitte benutzen wenn du von meheren Threads auf eine Variable zugreifst.

Original von IhateWin
wenn ich eine methode in einem eigenen thread starte und aus dieser herraus ein andere methode aufrufe, wird diese dann im gleichen thread ausgeführt ???

Ja.

(Du kannst nicht einfach in einem Methodenaufruf den Thread "wechseln", also wird alles vom ThreadState Delegate implizierte ausschliesslich im 2. Thread ausgeführt)

Es gibt ja die lock-Anweisung den man bei mehrfachzugriff auf eine Variable verwenden kann. Es gibt allerdings auch dieses Schlüßelwort "volatile". Wenn ich dieses für ein Feld einsetze wirkt es sich dann genauso aus wie eine enstprechende lock-Anweisung? Laut Hilfe könnte man das annehmen...

Wenn ich deine Frage richtig interpretiert habe, dann hast du gefragt, ob die Methode Machwas(), welche von der Tuwas() aufgerufen wird, wobei die Tuwas() in einem neuen Thread gestartet wurde, im Hauptprozess oder im Thread der Funktion Tuwas() läuft?

Ja, allerdings musst du wie schon in den vorherigen Posts bei Feldern und globalen Variablen darauf achen, dass diese beim Threadzugriff gesperrt werden, denn sonst könnte es unschöne Exceptions geben.

Frage von mir:
Wenn ich ein Interface außerhalb eines Threads implementiere aber die implementierte Funktion aus dem Thread heraus aufrufe, dann bin ich immernoch im selben Thread wie die Funktion in welcher das Interface aufgerufen wurde?

--
mfg
Franknstein

Generell: Die Ausführung bleibt im gleichen aktuellen Thread was immer du machst und wie viele Methoden da über welche Interfaces wie viel mal aufgerufen werden. Das Betriebssystem hat keinen Grund (und i.a. auch keine Möglichkeit) einfach aus Spass mal den Thread zu wechseln. Sogar Events werden Synchron im gleichen Thread bearbeitet. Ausnahmen: Explizites erstellen eines Threads, Invoke() sowie die asynchronen Begin/End Aufrufe.

Wenn ich ein Interface außerhalb eines Threads implementiere aber die implementierte Funktion aus dem Thread heraus aufrufe, dann bin ich immernoch im selben Thread wie die Funktion in welcher das Interface aufgerufen wurde?

Interfaces sind Typdefinitionen und haben keinen Einfluss auf das Thread-Verhalten.

Es gibt ja die lock-Anweisung den man bei mehrfachzugriff auf eine Variable verwenden kann. Es gibt allerdings auch dieses Schlüßelwort "volatile". Wenn ich dieses für ein Feld einsetze wirkt es sich dann genauso aus wie eine enstprechende lock-Anweisung? Laut Hilfe könnte man das annehmen...

Nicht wirklich. Das Lock Statement bewirk eine klassische Thread Synchronisation. Voilatile wird hingegen verwendet um auch ohne Synchronisation gemeinsam auf Variablen zugreifen zu können, wobei aber diverse Code Optimierungen deaktiviert werden müssen um einige Bedingungen zu garantieren.

Original von NoOneKnows
Es gibt ja die lock-Anweisung den man bei mehrfachzugriff auf eine Variable verwenden kann. Es gibt allerdings auch dieses Schlüßelwort "volatile". Wenn ich dieses für ein Feld einsetze wirkt es sich dann genauso aus wie eine enstprechende lock-Anweisung? Laut Hilfe könnte man das annehmen...

Ja und Nein. Für eine einfache Zuweisung der Variable mag das stimmen(Abbruchflag). Aber hast du komplexere Zuweisungen kommt es zu Race Conditions.

Also klassisches Bsp:

Thread1 bucht von Konto ab:

tmp = ReadKonto();
temp = temp - betrag;
WriteKonto(temp);

Thread2 macht was anderes mit dem Konto:

tmp = ReadKonto();
temp = temp + betrag;
temp = temp * zinsen;
WriteKonto(temp);

Schiebt sich jetzt ein Thread zwischen den Anderen kann es zu Inkosistenzen bei der Kontoführung kommen. Also must du beide Abschnitte komlett mit lock sperren (atomar machen).
Das obige Programm kann die unterschiedlichsten Ergebnisse hervorbringen, je nachdem wo der Scheduler die Threads unterbricht und neu startet.

Ja, allerdings musst du wie schon in den vorherigen Posts bei Feldern und globalen Variablen darauf achen, dass diese beim Threadzugriff gesperrt werden, denn sonst könnte es unschöne Exceptions geben.

Nicht unbeding zu Exceptions, das ist ja noch harmlos 😉 Das obige Beispiel ist noch recht einfach aber es kann zu bösen Fehlern und Inkonsistenzen kommen bei der parallenen Programierung, wenn deine Programme komplexer werden. Race Conditions sind manchmal schwer zu finden.

Frage von mir:
Wenn ich ein Interface außerhalb eines Threads implementiere aber die implementierte Funktion aus dem Thread heraus aufrufe, dann bin ich immernoch im selben Thread wie die Funktion in welcher das Interface aufgerufen wurde?

Du bist immer in dem Thread von wo du deine Funktionen aufrufst. Und in dieser Funktion bist du immer noch in deinem parallelem Thread.
Man kann nicht in einem anderem Thread/Elternprozess landen nur weil du eine externe Funktion aufrufst, das ist Quatsch 😉 Elternprozess und Thread arbeiten völlig unabhägig von einander.

Schiebt sich jetzt ein Thread zwischen den Anderen kann es zu Inkosistenzen bei der Kontoführung kommen. Also must du beide Abschnitte komlett mit lock sperren (atomar machen).
Das obige Programm kann die unterschiedlichsten Ergebnisse hervorbringen, je nachdem wo der Scheduler die Threads unterbricht und neu startet.

Durch CriticalSections kann man das relativ einfach unterbinden... habe ich jedenfalls immer gedacht.

Besten Dank zu den Interfaces!

--
mfg
Franksntein

@Franknstein

Was hast du immer wieder mit den Interface's?? Die haben überhaupt nix mit Thread's zu tun und helfen überhaupt nicht gegen die, von maxE beschriebene, Probleme.

@Xqgene
Ich habe mal eine Zeit lang Javaprogramme für Handys geschrieben.
Edit:
Aber du hast Recht, ich sollte das echt lassen. Denn bei der Windowsprogrammierung ist das nicht so sinnig alle diesen Kniffe zum Speicher sparen zu verwenden.

--
mfg
Franknstein

Durch CriticalSections kann man das relativ einfach unterbinden... habe ich jedenfalls immer gedacht.

Ja klar, das Schlüsselwort lock ist so was ähnliches wie ne binäre Semaphore und damit im Endeffekt nichts weiter als ne Critical Section 😉