Fehlermeldung "Element hat kein übergeördnetes Fenster"

[devidespe]

Zitat von quendolineDD:

Und du solltest auch strikt VCL und Threads voneinander trennen. Die Threads machen keinen Sinn wenn du andauernd über Synchronize auf den Mainthread zugreifst.

Das Problem hier im Test und später in der produktiven Anwendung ist ja, dass der Thread seine Arbeit verrichtet und die Ergebnisse in einem Memo schreiben muss. Insofern ist eine Verknüpfung zwischen Thread und VCL leider nicht wegzudenken, zumindest in meinem Fall. Mit der private Deklaration eines Memos innerhalb des Threads habe ich das aber hoffentlich effektiv gelöst. Oder ist das eher kontraproduktiv ? Wie könnte man es sonst umsetzen ?

[quendolineDD]

Und wenn du dir zur Synchronisation einen Container baust, der alle Threads beherbergt und verwaltet? Das wäre glaube sinnvoller als für jeden Thread aufgrund einer anderen ID eine eigene Klasse zu schreiben

[himitsu]

Du hast doch in dem BEispiel 3 Threads, wleche im Grunde alle das Selbe machen, ist das in der "produktiven" Anwendung später auch so?

Denn so wie es jetzt ist, könnte mann alle Threads durch eine Thread-Klasse ersetzten.

[devidespe]

Zitat von himitsu:

Du hast doch in dem BEispiel 3 Threads, wleche im Grunde alle das Selbe machen, ist das in der "produktiven" Anwendung später auch so?

Denn so wie es jetzt ist, könnte mann alle Threads durch eine Thread-Klasse ersetzten.

Nein, die Threads erfüllen später unterschiedliche Aufgaben, nur eben für diese Beispielanwendung habe ich es einfach gehalten.

[quendolineDD]

Dann schreibe dir eine Containerklasse, die die Threads verwaltet und die Ausgabe übernimmt.

[devidespe]

Zitat von quendolineDD:

Dann schreibe dir eine Containerklasse, die die Threads verwaltet und die Ausgabe übernimmt.

Oje, dazu muss ich mir erst mal ein Tutorial heraussuchen, da ich mit Containerklassen und Threads nicht so bewandert bin.

[devidespe]

Ich benötige noch einmal Hilfe bzgl. dieser Thread-Beispielanwendung. Wenn ich anstatt der 3 Threads das ganze auf 10 Threads jeweils mit 10 Memofeldern ausweite, scheint das Fenster nicht mehr auf Aktionen zu reagieren. Dies betrifft etwa das Verschieben des Fensters oder das Drücken des Abbrechen-Schalters. Auch ein Verwenden von Application.ProcessMessages ändert daran nichts.

Anbei noch einmal die Beispielanwendung mit 10 Threads anstatt mit 3 Threads. Was kann man da machen ?

Dass die Belastungsgrenze des Prozessors erreicht ist, kann ich mir nicht vorstellen. Der Prozess errteicht ja nichtmal 50 Prozent CPU-Auslastung. Die Threads verrichten ausserdem noch keine eigentliche Arbeit, sondern schreiben nur Zufallszahlen ins Memo. Bin über jede Hilfe dankbar.

[himitsu]

Du mußt bedenken, daß die Thread die Ganze Zeit über eigentlich nichts anderes machen, als den Hauptthread zu sperren und den Memos was übergeben (was die meußte Zeut eines Threads passiert, da er sonst nix macht) ... tja und der Hauptthread hat dann kaum noch Zeit sich um die VCL zu kümmer, also daß die Form und alles darauf reagiert.

PS: warum die Threads nicht soviel CPU-Last verbrauchen, liegt daran, daß sie sehr viel Zeit nichts tun, da sich oftmals darauf Warten, daß der Hauptthread mal Frei wird, damit sie auch endlich mal darauf zugreifen können.

[thkerkmann]

Hi,

also auf meinem nicht mehr ganz so jungen Laptop läuft das Programm ganz flüssig.
Wenn Du das allerdings im Debugger laufen läßt kannst du die Performance nicht mehr beurteilen, da der Debugger viel zu viel Leistung verbraucht um deine Threads zu kontrollieren.

Allerdings ist mir aufgefallen, dass du zuviel (nämlich die ganze) Arbeit innerhalb von Synchronize verrichtest.

Delphi-Quellcode:

Procedure TBeispielThread4.DoThread;
begin
  randomize;
  FMemo.lines.add('Test Thread 4 - '+IntToStr(Random(200)));
end;

Es sollte eigentlich die Berechnung...

Delphi-Quellcode:

  ...
  Randomize; // auch schon hier nicht so toll, nur einmal pro Programminstanz
  zufallszahl := Random(200); // zufallszahl = membervariable des threads, ebenso logstring
  logstring := 'Test Thread 4 - ' + IntToStr(Zufallszahl);
  Synchronize (Ausgabe);
  ....

von der Ausgabe mit Synchronize getrennt werden.

Delphi-Quellcode:

procedure TThread4.Ausgabe;
begin
  FMemo.Lines.Add(logstring);
end;

Es kommt grundsätzlich darauf an, die Zeit innerhalb einer Synchronize ten Methode so kurz wie möglich zu halten, und die zeitaufwändigen Teile innerhalb der Thread.Execute zu halten.

Gruss

[edit]falsche Quelltextformatierung[/edit]

[devidespe]

@thkerkmann: Ich habe Deine Tips beherzigt und die eigentlichen Berechnungen in Execute untergebracht. Der Umstand, dass ich bei sehr aktiver Verwendung der Memos ein nicht mehr reagierendes Fenster habe, bleibt allerdings bestehen.

Hier habe ich etwas experimentiert und mal eine Sleep-Funktion eingefügt (etwa 500 Ticks vor jedem Schreibvorgang) und siehe da, dem Hauptthread bleibt wieder mehr Zeit für Reaktionen. In diesem Maße wie hier in der Beispielanwendung auf die Memos zugegriffen wird, ist das in der produktiven Anwendung natürlich nicht der Fall.

Man könnte neben den eigentlichen Thread-Prioritäten auch die Fenster-Priorität erhöhen, ich glaube hierfür gibt es TForm1.SetPriority mit den 4 Prioritätsklassen Idle_Priority_Class, Normal_Priority_Class, High_Priority_Class und Realtime_Priority_Class.