Thread legt das gesamte Betriebssystem lahm

[Frank Kneffel]

Hallo, wir haben hier bei uns zwei Win 2000 Rechner mit Delphi 6 drauf. auf beiden wird der folgende thread ausgeführt:<br>
<pre>
unit Unit2;

interface

uses
sysutils,forms,windows,Classes;

type
test = class(TThread)
private
{ Private-Deklarationen }
protected
procedure Execute; override;
procedure update;
end;

implementation
uses unit1;
{ test }

procedure test.Execute;
begin
{ Thread-Code hier einfügen }

repeat
Synchronize(update);
application.processmessages;
until terminated;
end;

procedure test.update;
begin
form1.caption:=timetostr(time);
end;

</pre>
Wenn wir das Compilieren zeigt sich folgendes Bild: <br>
Exe von Rechner 1: Läuft auf Rechner 1 und 2 problemlose.
Exe von Rechner 2: Läuft auf Rechner 1 problemlos, stoppt Rechner 2. <br>
Das Fehlerbild, was sich zeigt ist dabei, dass anscheinen die Windowsbotschaften nicht mehr schnell genug abgearbeitet werden. Drückt man Alt+F4 kann es mehrere 10 Sekunden dauern, bis das Programm geschlossen ist. Das Problem was wir aber dabei haben, ist daß die Exe vom Rechner 2 auch auf anderen Rechnern (bis auf Rechner 1) das gleiche Problem zeigt. Hat jemand ein Idee, wonach wir hier suchen könnten ?

[Andreas Kosch]

Hallo,

&gt;Thread legt das gesamte Betriebssystem lahm

die folgende Implementierung einer Endlos-Schleife verbrät nur die CPU-Rechenzeit, die von anderen Prozessen/Threads nicht benötigt wird:
<pre>
procedure test.Execute;
begin
repeat
Synchronize(update);
Application.processmessages;
until terminated;
end;
</pre>
Da der separate Thread in der Schleife <b>keine</b> Wartezeit über <b>Sleep</b> (oder <b>WaitForSingleObject</b> etc.) einlegt, erhält er vom Scheduler alle die Rechenzeit, die andere Prozesse übriglassen. Da der Scheduler auch die <b>Priorität</b> eines Threads berücksichtigt, hängt es auf jedem Rechner von den restlichen laufenden Prozessen ab, wie sich diese Anwendung in der Praxis verhält.

&gt;Drückt man Alt+F4 kann es mehrere 10 Sekunden dauern, bis das Programm geschlossen ist.

Nicht fehlen darf in diesem Zusammenhang mein Standard-Hinweis, dass TThread und Synchronize ab Delphi 6 aufgrund der Anpassungsarbieten an Kylix ein Stück gelitten haben. Im Borland-Papier "<i>Changes to TThread in Delphi 6 and Kylix</i> (Article ID: 27655) ist die folgende, in fetter (roter) Schrift hervorgehobene Warnung zu finden: "<i>This may make your program behave differently under Delphi 6 than it did in Delphi 5, so you may want to <b>follow</b> calls to Application.ProcessMessages with a <b>call</b> to <b>CheckSynchronize</b>.</i>". Außerdem gibt es da noch den inoffiziellen Bugfix "<i>Updated Version of TThread.Synchronize for Delphi 6.0</i>", der aber nur etwas an den Symtomen herumdockert, ohne das grundlegende Problem zu lösen.

Lange Rede - kurzer Sinn: Ab Delphi 6 reicht es <b>nicht</b> mehr aus, einfach nur <i>Application.ProcessMessages</i> aufzurufen! Wer unter allen Umständen eine saubere Thread-Implementierung haben möchte, muss auf TThread verzichten und statt dessen direkt mit den Win32-API-Funktionen arbeiten - es sei denn, er wechselt zu Delphi 5 zurück :-

[Frank Kneffel]

Ok, danke für den Hinweis.<br>
Es war mir schon klar, dass der Thread die gesamte freie Prozessorleistung in Anspruch nimmt, was in unserem Fall aber nicht tragisch gewesen wäre, wenn der Rechner auf die Maus bzw. die Tastatur noch reagiert hätte, allerding hatte ich von dem Threadproblem ab Delphi 6 nocht nichts gehört.<br>
Wie sieht es denn mit Delphi 7 aus, wir wollen demnächst wechseln. Ist die Implementierung dort besser ? Wenn ich Deine Aussage richtig interpretiere scheint das ja nicht der Fall zu sein

[Andreas Kosch]

Hallo,

&gt;Ist die Implementierung dort besser ?

nein

[Michael Habbe]

Hi.

<pre>
procedure test.Execute;
begin
{ Thread-Code hier einfügen }<br>
repeat
Synchronize(update);
application.processmessages;
until terminated;
end;
</pre>

Ist es hier nicht generell sinnvoller (ich weiss nicht, obs Probleme mit der Version gibt, hab bisher nur mit Version 5 gearbeitet), wenn man dort ein Sleep(5-10) anstelle von application.processmessages einfügt?
Dadurch wird dem Hauptprozess doch auch Zeit gegeben, auf Meldungen zu reagieren, oder?

mf

[Andreas Kosch]

Hallo,

in der Tat ist Sleep (oder vergleichbares) an dieser Stelle sinnvoll, aber nur als Ergänzung. Das Ganze macht eher in der Kombination von <b>Sleep</b> + <b>ProcessMessages</b> + <b>CheckSynchronize</b> einen Sinn, wenn in der Schleife ein Aufruf von Synchronize vorkommt

[Frank Kneffel]

Wenn ich allerdings CheckSynchronize aufrufe bekomme ich folgende Meldung:<br>
<Pre>
---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt USVService.exe ist eine Exception der Klasse EThread aufgetreten. Meldung: 'CheckSynchronize wurde vom Thread $74C aufgerufen, der NICHT der Haupt-Thread ist.'. Prozeß wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK Hilfe
---------------------------
</pre>
Muß ich erst den "Updated Version of TThread.Synchronize for Delphi 6.0" installieren, damit ich Checksynchronize aufrufen kann