Threads (tpIdle) blokieren Anwendung

[Manfred D2009]

Nach der letzten Anregung und etwas grübeln habe ich folgende Lösung integriert:

- jeder Thread erhält ein Signal
- statt den einfachen Sleep-Aufrufen wartet ein Thread nun auf das Signal oder eine bestimmte Zeit (ähnlich wie beim Sleep). Die "Wait"-Zeit habe ich höher gesetzt als bei den Sleep-Aufrufen, damit gibt es weniger Blockaden durch synchronisierte Abschnitte.
- Ist der Hauptthread ohne Arbeit (OnIdle-Ereignis) oder sollen die Threads beendet werden, so werden die Signale abgefeuert, so dass die Threads gar nicht warten müssen.

Die ersten Tests waren vielversprechend und die Berechnungen sind im Idle-Fall sogar schneller als vorher...

[Iwo Asnet]

Zitat:

Zitat von Manfred D2009 (Beitrag 1171530)

- statt den einfachen Sleep-Aufrufen wartet ein Thread nun auf das Signal oder eine bestimmte Zeit (ähnlich wie beim Sleep). Die "Wait"-Zeit habe ich höher gesetzt als bei den Sleep-Aufrufen, damit gibt es weniger Blockaden durch synchronisierte Abschnitte.
- Ist der Hauptthread ohne Arbeit (OnIdle-Ereignis) oder sollen die Threads beendet werden, so werden die Signale abgefeuert, so dass die Threads gar nicht warten müssen.

:shock: Lese ich da 'Sleep'? 'Wait'?... Au backe. Verwende Synchronisationsobjekte (Semaphoren, Mutexe und so'n Kram).


Mit der Aktualisierung in einem Formular würde Ich das lösen, in dem ich dem Hauptformular per 'PostMessage' ein paar Daten zur Anzeige schicke: Der Thread instantiiert ein Datenobjekt, das er mit Daten füllt. Per PostMessage geht es dann zum Hauptthread (dem Formular z.B.) welches das Objekt übernimmt, anzeigt und zersört. Das ist asynchron.

Delphi-Quellcode:

TThread.Queue

dürfte so oder ähnlich arbeiten.

Du solltest allerdings nicht beliebig viele Synchronize/Queue/PostMessage-Aufrufe durchführen. Alleine damit kann man sich sein System blockieren.

[BUG]

Zitat:

Zitat von Iwo Asnet (Beitrag 1171574)

Alleine damit kann man sich sein System blockieren.

Und genau das war/ist sein Problem.

Zitat:

Zitat von Iwo Asnet (Beitrag 1171574)

:shock: Lese ich da 'Sleep'? 'Wait'?... Au backe. Verwende Synchronisationsobjekte (Semaphoren, Mutexe und so'n Kram).

Wenn ich das richtig deute, werden die waits mit "richtigen" Synchronizationsmitteln (Signal -> Semaphore?) realisiert. Das Warten dient nur dazu, die Message-Queue zu entlasten.

[Manfred D2009]

Zitat:

Und genau das war/ist sein Problem.

Ja, genau das war (hoffentlich) mein Problem...

Zitat:

Wenn ich das richtig deute, werden die waits mit "richtigen" Synchronizationsmitteln (Signal -> Semaphore?) realisiert.

Ich verwende jetzt Semaphore, habe das nur etwas salopp formuliert.

[Iwo Asnet]

Gut. Ich hatte mich spät eingelesen und wollte nur wichtigtuerischen Senf dazugeben.
[x] gut erkannt, BUG ;-)

[BUG]

Nur der Vollständigkeit halber, Manfred D2009s Lösung passt vermutlich besser zu seinem Problem:

Zitat:

Zitat von Manfred D2009 (Beitrag 1171011)

Wie meinst du das mit "Thread soll niedrig priorisierten Message an den Hauptthread schicken"? Gibt es eine Möglichkeit die Messages zu priorisieren (hab ich noch nie gemacht)?

Dieses fehlende Bauteil hat soeben WladiD geliefert :thumb:

Zitat:

Zitat von WladiD (Beitrag 1172840)

Benutze lieber einen Timer oder meinetwegen meine TDelayedMethod-Klasse:

Delphi-Quellcode:

//...
TDelayedMethod.Execute(frmMain.ZeichneUebersichtNeu); // Wird über WM_TIMER ausgeführt (also niedrigste Prio)

Man beachte auch:

Zitat:

Zitat von http://wladid.de/delphi/klasse-fur-die-einfache-verwendung-von-verzogernden-methoden/

Eine eindeutige Methode kann stets nur einmal hinzugefügt bzw. ausgeführt werden.
Wurde zuvor die selbe Methode schon mal übergeben, so ersetzt der letzte Aufruf den vorherigen.

Das würde natürlich gut zu der von mir vorgeschlagenen Lösung passen :mrgreen:
Ich hatte nach der Lektüre dieses Artikels auch WM_TIMER oder WM_PAINT im Kopf, fühlt mich damit aber nicht sicher genug, irgendwelche konkreten Vorschläge/Implementierungen zu machen.


Falls also jemand eine niedrig-priore Nachricht aus Threads schicken will, so könnte (höchst ungetestet / nicht implementiert) es gehen:

• Nachricht in threadsichere Queue eintragen
• TDelayedMethod (im Main-Thread erstellen) benutzen, um Main-Thread die Nachricht zu signalisieren
• Dort kann man dann nach belieben Nachrichten aus der Queue bearbeiten und erneut signalisieren, wenn Queue nicht leer ist, aber erstmal die echte Message-Queue abgearbeitet werden soll.