Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Threadlogik Problem (https://www.delphipraxis.net/119229-threadlogik-problem.html)

stOrM 22. Aug 2008 16:35


Threadlogik Problem
 
Hallo,
ich steht grad auf dem Schlauch, ich hab ein kleines Logikproblem, bezüglich 2'er Threads...

Der 1. Threads muß immer an sein, es sei denn der User klickt auf Stop... So eine Art WatcherThread...
Der 2. Thread ich nenn Ihn mal WorkerThread, soll nur dann aktiv sein, wenn der 1. Thread etwas bestimmtes gefunden hat, dann soll der Workerthread etwas ausführen uns zwar nur einmal, und sich dann selber beenden.

Das Problem ist, wenn ich das mal auf folgendes Szenario abbilde:

1. Thread findet ein bestimmtes Fenster, jetzt ruft er den 2. Thread auf, dieser sendet eine Nachricht, an das vom Thread 1 gefundene Fenster, jetzt muß ich ja irgendwie sicherstellen, das wenn die Nachricht versendet wurde, der 2. Thread sich beendet.
Mir ist nur unklar woran ich das festmachen soll, weil ja der 1. Thread den 2. Thread created wenn das Fenster sichtbar ist.

Das wäre ja dann ne art Endlosschleife? Was ich vermeiden muss irgendwie ohne den 1. Thread zu killen.

Ich hoffe das mir jemand in mein Chaos folgen kann und einen Tip für mich hat...


Viele Grüsse
s!

alias5000 22. Aug 2008 18:01

Re: Threadlogik Problem
 
Warum soll das eine Endlosschleife sein?

Vom Verlauf her sieht das doch so aus:
Code:
1. Thread läuft in einer (abbrechbaren) Endlosschleife und sucht ständig nach so einem Fenster
 -
 -
\/
1. Thread findet ein Fenster, erstellt und startet einen WorkerThread
 -
 -
\/
Der Worker-Thread arbeitet nicht in einer Endlosschleife, sondern sendet eine Nachricht (WM_??) an das Fenster und dann ist die Execute-Methode vorbei
 -
 -
\/
1. Thread bekommt, wenn benötigt, über das OnTerminate Ereignis mit, wenn der WorkerThread fertig ist
Wenn du beim WorkerThread FreeOnTerminate auf True setzt, dann gibt er sich ja selbstständig frei, wenn die Execute-Methode rum ist und er sich somit terminiert.

Ist damit dein Problem geklärt, oder wohin solls genau gehen?

Gruß
alias5000

stOrM 22. Aug 2008 18:15

Re: Threadlogik Problem
 
Zitat:

Zitat von alias5000
Warum soll das eine Endlosschleife sein?

Vom Verlauf her sieht das doch so aus:
Code:
1. Thread läuft in einer (abbrechbaren) Endlosschleife und sucht ständig nach so einem Fenster
 -
 -
\/
1. Thread findet ein Fenster, erstellt und startet einen WorkerThread
 -
 -
\/
Der Worker-Thread arbeitet nicht in einer Endlosschleife, sondern sendet eine Nachricht (WM_??) an das Fenster und dann ist die Execute-Methode vorbei
 -
 -
\/
1. Thread bekommt, wenn benötigt, über das OnTerminate Ereignis mit, wenn der WorkerThread fertig ist
Wenn du beim WorkerThread FreeOnTerminate auf True setzt, dann gibt er sich ja selbstständig frei, wenn die Execute-Methode rum ist und er sich somit terminiert.

Ist damit dein Problem geklärt, oder wohin solls genau gehen?

Gruß
alias5000

Also ich habs nu ungefähr so, dass Problem ist, das der WorkerThread nicht beendet, anstelle dessen sendet er ohne ende ne Nachricht an das Fremdfenster, dass soll er aber nur einmal machen, dass Problem ist, wie bekomme ich denn das so hin:

Der 1. Thread muss ja unendlich nach einem Fenster suchen, wenn diese gefunden wird den Workerthread starten, dieser sendet die Nachricht und soll sich beendet wenn die Nachricht versendet wurde, was aber wenn das Fenster Fremdfenster nicht geschlossen wurde? Thread1 startet ja dann wieder Thread2? Genau das ist ja das Problem.

Szenario 2
Thread1 findet das Fenster, Worker wird gestartet sendet die Nachricht und würde beendet werden, Fremdfenster wurde geschlossen.
Fremdfenster wird erneut aufgerufen, also wieder alles von vorne! Das ist mir völlig unklar logiktechnisch...

Ich zeigs mal per Code vielleicht wirds dann deutlicher:

Delphi-Quellcode:
constructor TMozWatchDogThread.Create;
begin
  inherited create(true);
   freeOnTerminate := true;
   Priority := tpLowest;
end;

destructor TMozWatchDogThread.destroy;
begin
  inherited destroy;
end;

procedure TMozWatchDogThread.Execute;
begin
  while not(Terminated = true) do
   begin
      // Suche Fenster wenn handle > 0 dann
      // StarteWorkerThread;
      // hat workerthread nachricht gesendet und ist fremdfenster geschlossen,
      // dann alles von vorne, hat worker nachricht gesendet aber fenster noch offen
      // dann nicht erneut nachricht an fremdfenster senden!
     end;
end;

{ TMozWatchDogWrokerThread }

constructor TMozWatchDogWorkerThread.create;
begin
  inherited create(true);
  freeOnTerminate := true;
  Priority := tpLowest;
end;

destructor TMozWatchDogWorkerThread.destroy;
begin
  inherited destroy;
end;

procedure TMozWatchDogWorkerThread.Execute;
begin
  // sende nachricht an fremdfenster, dann beende dich selber

end;
Gruss
s!

alias5000 22. Aug 2008 19:36

Re: Threadlogik Problem
 
Das ist dann eher eine Frage der Anwendungslogik.
Was genau soll sie machen und wie soll sie auf bestimmte Szenarien reagieren?

Gerade Szenario 1 würde ich mir erstmal ohne eine konkrete Umsetzung überlegen, sondern erstmal, was das gewünschte Verhalten der Anwendung ist.
Dann ist die Umsetzung einfacher.
Beispiel: Wenn deine Mozilla-Software (liege ich richtig?) nicht geschlossen wird, trotz WM_CLOSE, oder was du sendest, dann musst du dir überlegen, wie du damit von der Anwendungslogik her umgehst. Soll eine MessageBox hochgehen, wenn die Anwendung nicht innerhalb von 10 Sekunden geschlossen wird,...?

Sowas in die Richtung

Gruß
alias5000

stOrM 22. Aug 2008 19:41

Re: Threadlogik Problem
 
Nochmal anders erklärt, sagen wir der User öffnet in Mozilla den speichern dialog, worauf Thread 1 lauscht, sollte das der Fall sein soll Worker ne message in den Dialog von Moz posten, was auch passiert, nur kann ich den Dialog ja nicht killen, weil der User eventuell noch nen anderen Pfad wählen will oder sonstiges daher prüfen ob Handle des Dialogs > 0 ist

alias5000 23. Aug 2008 11:09

Re: Threadlogik Problem
 
Ja gut, aber im 1. Thread wirst du ja sehen, ob gerade ein Speicherndialog mit einem bestimmten Handle offen ist, oder nicht.
Du kannst dann ja einfach im 1. Thread ne Bool-Variable benutzen, die auf true gesetzt wird, wenn ein neues Fenster gefunden wurde und dazu ein Thread erstellt wurde. Der Workerthread verrichtet dann seine Arbeit und beendet sich. Solange die Boolean-Variable zu dem spezifischen Handle true ist, wird kein neuer Thread erstellt. Wenn dann der 1.Thread feststellt, dass das Handle dieses gefundenen Dialoges = 0 ist, setzt er die Bool-Variable zurück und würde somit später wieder einen Workerthread erstellen, wenn ein neuer Dialog geöffnet würde

Verstanden, was ich meine?

Gruß
alias5000

stOrM 23. Aug 2008 11:15

Re: Threadlogik Problem
 
Theretisch ja, nur praktisch hat auch das nicht funktioniert, frag mich nicht warum, irgendwie beendet sich der worker ned :-(

alias5000 23. Aug 2008 11:46

Re: Threadlogik Problem
 
Code?

NormanNG 23. Aug 2008 12:26

Re: Threadlogik Problem
 
Hi,

Zitat:

Zitat von stOrM
Theretisch ja, nur praktisch hat auch das nicht funktioniert, frag mich nicht warum, irgendwie beendet sich der worker ned :-(

Könnte es nicht sein, das der Workerthread "normal" läuft und beendet wird,
aber der WatchDogThread das Fenster immer wieder findet und immer
neue WorkerThread startet?

Das will wohl auch alias5000 mit dem Boolean verhindern.

thkerkmann 23. Aug 2008 13:08

Re: Threadlogik Problem
 
Hi,

Wieso willst Du überhaupt nur um eine Nachricht zu senden, eine extra Thread starten ?
Ich sehe da keinen Sinn drin, wenn der WatchThread sowieso erst wissen muss, ob das geklappt hat oder nicht, kann er's ja auch selber machen. Das vereinfach die Logik, macht das Programm schlanker und effizienter (ein extra Thread heißt ja auch extra Verwaltung) und dich glücklicher ;-)

Gruss


Alle Zeitangaben in WEZ +1. Es ist jetzt 23:20 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz