Problem mit threads

TheHolyMan · Beiträge: 22

Also folgendes

ich habe eine Thread der die aufgabe hat über eine spezielle komponente Daten über die serielle Schnitstelle zu senden und zu empfangen

der thred gehört einer "form" damit ich auf die Ereignisse reagieren kann.

nun ist folgendes Problem aufgetreten

der thread muss manchmal eine funktion ausführen die über 10 sekunden nur warten muss .. in dieser Zeit werden aber keine ereignissse mehr ausgeführt.

im hauptprozess könnte man das mit application.processmessages lösen .. aber in einem thread?

herzi · Beiträge: 168 WINXP pro, SUSE Linux 9.0 D7 Pers.

Friert das Formular dann ein ?

Dafür gibts TAntiFreeze!

TheHolyMan · Beiträge: 22

nein allgemein ... sobald der thread in einer warteschleife ist werden keine ereignisse mehr aufgerufen!!

Ehemaliges Mitglied Erhaltene Danke: 1

Kann nicht sein. Warum sollten keine Ereignisse für das Hauptfesnter aufgerufen werden, wenn sich der zweite Thread in einer Warteschleife befindet? Was ist das überhaupt und wie sieht sie aus?

TheHolyMan · Beiträge: 22

nein .. also alles spielt sich in einem thread ab ...

der thread reagiert auch auf ereignisse ... aber wenn er in einer warteschleife hängt werden die ereignisse für den thread nicht mehr aufgerufen

Ehemaliges Mitglied Erhaltene Danke: 1

Irgendwie logisch oder? Warum sollte sich ein separater Thread anders verhalten, wie der Hauptthread von deinem Fenster? Auch ein separater Thread kann keinen Code an zwei Stellen gelichzeitig ausführen (Auf Ereignisse reagieren und in deiner Warteschleife hängen.)

Was soll das überhaupt mit der Warteschleife in dem Thread? Auf was wird gewartet? Und warum wird gewartet? ich fürchte du hast ein ziemliches Design Problem.

Windows bietet dir die Möglichkeit mit Ereignissen zu arbeiten, die Zeiten des Pollings in einer Schleife sind eigentlich vorbei.

TheHolyMan · Beiträge: 22

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

er verhält sich eben nicht gleich ....

while a < 1000 do begin 
  ..  
  .. // polling der einzelnen com-geräte (status abfragen und auf antwort warten)
  Application.processMessages
end;


Procedure tmr1.OnTimer()
begin
  ...
  ...
end;

wenn sich dieser code allein in einem hauptprogramm befinden funktioniert alles ...
durch Application.processMessages wird das Timerevent richtig aufgerufen.

befindet sich das jedoch in einem thread .. dann wird das ereignis nicht aufgerufen.

Zitat:

ich fürchte du hast ein ziemliches Design Problem.

isch muss nur eine änderung vornehmen am programm ... *argh*

Moderiert von Tino: Code- durch Delphi-Tags ersetzt.

TheHolyMan · Beiträge: 22

weiss keiner weiter?

.Chef · Beiträge: 1112

Du hast wirklich ein Designproblem. Der Sinn von dem Thread ist ja, dass man pollen kann, ohne dass das Hauptprogramm einfriert. Im selben(!) Thread während des Pollens noch etwas anderes parallel zu machen widerspricht der Logik seines Daseins. Wenn du also mehr Aktivitäten brauchst, nimm mehrere Threads!

_________________
Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

Also ich denke auch mal, dass du ein Designproblem hast. Normal würde ich die Fenster und die Arbeit (Comschnittstelle) in seperate Threads packen. Die Fenster entweder im VCL-Thread oder in einem Thread, der nur für das Fenster zuständig ist. Und die kompletten COM Sachen alle in einem eigenen Thread. Wenn dieser dann blockiert reagieren die anderen Threads noch wie gewohnt. Dann brauchst du auch nicht so etwas wie Application.ProcessMessages machen. Was ich persönlich für die schlechteste Alternative halte, da es auch Schwierigkeiten mit sich bringen kann.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme