Thread soll eine Minute warten: Sleep oder Timer?

[nuclearping]

GetTickCount ist Windows API und fragt die Millisekunden seit dem letzten Systemstart ab. Da unterbricht nix.

[Bbommel]

Zitat:

Zitat von Zoot

Zitat:

Zitat von Reinhard Kern

Hallo,
Weder Thread noch sleep nötig.

Verstehe auch nicht, wozu man einen Thread braucht, wenn der eh normalerweise nix tut.
Ein simpler timer reicht doch dann völlig.

Weil das nur ein stark vereinfachtes Beispiel war, bei dem es mir um das Problem mit dem sauberen Beenden ging. Im realen Programm wird es um eine Datenbank-Abfrage gehen. Und wenn man das schon mal gemacht hat, weiß man, dass Verbindungsaufbau und/oder Abfrage gerne mal ein paar Sekunden dauern. Da wäre es für den Anwender nicht so schön, wenn ihm plötzlich die Anwendung einfriert, obwohl er nix gemacht hat.

Jetzt klarer?

Bis denn
Bommel

[Reinhard Kern]

Zitat:

Zitat von Bbommel

Zitat:

Zitat von Zoot

Zitat:

Zitat von Reinhard Kern

Hallo,
Weder Thread noch sleep nötig.

Verstehe auch nicht, wozu man einen Thread braucht, wenn der eh normalerweise nix tut.
Ein simpler timer reicht doch dann völlig.

Weil das nur ein stark vereinfachtes Beispiel war, bei dem es mir um das Problem mit dem sauberen Beenden ging. Im realen Programm wird es um eine Datenbank-Abfrage gehen. Und wenn man das schon mal gemacht hat, weiß man, dass Verbindungsaufbau und/oder Abfrage gerne mal ein paar Sekunden dauern. Da wäre es für den Anwender nicht so schön, wenn ihm plötzlich die Anwendung einfriert, obwohl er nix gemacht hat.

Jetzt klarer?

Bis denn
Bommel

Hallo Bommel,

welche Anwendung soll denn einfrieren? Das Hauptprogramm bekommt nur Messages zum Beenden und führt diese sofort aus, oder Timer-Messages und zeigt dann Daten an oder was auch immer, was man vernünftigerweise sowieso nicht unterbricht. Ausserdem kann man das leicht gegeneinander sperren, so dass nur beendet wird, wenn gerade keine Daten verarbeitet werden, und man kann die Datenverarbeitung abbrechen, wenn das Programm beendet werden soll, beides hat nichts mit Threads zu tun.

Der grösste Nachteil meiner Lösung, das muss ich zugeben, ist, dass man nicht damit angeben kann, was für tolle Multithreads man schreiben kann. Mit einfachen Lösungen macht man sich hier hochgradig unbeliebt. Also vergiss es einfach und mach einen, zwei, viele Threads.

Gruss Reinhard

[himitsu]

Zitat:

Zitat von Bbommel

Nur zum Verständnis noch mal nachgefragt: Das ist ja eigentlich der gleiche Ansatz, Wie ich ihn mit dem mehrfachen Hochzählen von i und dazwischen einem kürzeren sleep hatte, nur über den TickCount eleganter, weil die 60 Sekunden besser eingehalten werden können, richtig?

genau :angel:

Zitat:

Zitat von Bbommel

Mein Problem mit dem Ansatz ist nur, dass es sich komisch "anfühlt", wenn andauernd ein Kontextwechsel gemacht wird, obwohl eigentlich gar nichts zu tun ist. Ich kann nur überhaupt nicht einschätzen, ob sowas auch tatsächlich nach bemerkbar ist oder ob ich mir dann den Kopf über ein eher akademisches Problem zerbreche. :)

Also nach meinen Erfahrungen/Tests sind, je nach Einsatzgebiet, 50-200ms für den Menschen kaum merkbar und für den Prozessor sind die Intervalle wiederum so groß, daß diese ihn auch nicht sehr stören.

Ich halte beides für "gute" Möglichkeiten dieses zu regeln (WaitFor und soeine kleine Sleep-Schleife) ... es kommt nur darauf an, wieviel du implementieren willst und wie schnell das Abbrechen Programmintern sein soll ... das WaitFor... reagiert natürlich schneller, ist aber 'nen Hauch aufwendiger.

[Bbommel]

Zitat:

Zitat von Reinhard Kern

welche Anwendung soll denn einfrieren? Das Hauptprogramm bekommt nur Messages zum Beenden und führt diese sofort aus, oder Timer-Messages und zeigt dann Daten an oder was auch immer, was man vernünftigerweise sowieso nicht unterbricht.

Es geht mir aber doch nicht um das Anzeigen der Daten - da hast du recht, das sollte ausreichend schnell sein und auch nicht unterbrochen werden - sondern um das BESCHAFFEN der Daten. Würde ich das ohne Threads, sondern direkt im Timer machen, dann würde der Benutzer in einem Moment ganz normal mit dem Programm arbeiten können und im nächsten Moment reagiert das Programm nicht mehr, weil gerade versucht wird, eine Verbindung zu einem Datenbank-Server aufzubauen (der ja vielleicht sogar im schlimmsten Fall nicht erreichbar ist). Während dieser 3-10 Sekunden würde die Anwendung aus Sicht des Benutzers stehen, der sich wundert, was er falsch gemacht hat.

Das Aktualisieren der Komponenten, also das Anzeigen der Daten, geschieht dann natürlich wieder über den Hauptthread.

Ich sehe nicht, wo ich da gerade zu kompliziert denke und wie man das einfacher lösen könnte. Aber wenn ich mich da irgendwie verrannt habe und du eine einfachere Lösung siehst, gerne her damit.

Bis denn
Bommel

[sirius]

Zitat:

Zitat von Reinhard Kern

beides hat nichts mit Threads zu tun.

Aber, wie der OP schon schrieb, Datenbankabfragen gehören sehr wohl in Threads. Ich verstehe gar nicht, was es darüber zu diskutieren gibt.

[Dezipaitor]

Ich bin für
WaitForSingleObject(hStopThreadevent, 20*1000)

[Frederika]

Zitat:

Zitat von Bbommel

Würde ich das ohne Threads, sondern direkt im Timer machen, dann würde der Benutzer in einem Moment ganz normal mit dem Programm arbeiten können und im nächsten Moment reagiert das Programm nicht mehr, weil gerade versucht wird, eine Verbindung zu einem Datenbank-Server aufzubauen (der ja vielleicht sogar im schlimmsten Fall nicht erreichbar ist). Während dieser 3-10 Sekunden würde die Anwendung aus Sicht des Benutzers stehen, der sich wundert, was er falsch gemacht hat.

Ne, die normale Lösung ist eigentlich, einen Timer im Hauptprogramm zu haben, der dann jeweils einen Thread startet. Der Thread selbst beendet sich immer sofort nach erledigter Aufgabe. Da muß niemand auf irgendwas warten.

[sirius]

Zitat:

Zitat von Frederika

Ne, die normale Lösung ist eigentlich, einen Timer im Hauptprogramm zu haben, der dann jeweils einen Thread startet. Der Thread selbst beendet sich immer sofort nach erledigter
Aufgabe. Da muß niemand auf irgendwas warten.

Dazu würde ich gern nähere Gründe wissen.
Gerade bei Datenbankanwendungen mache ich es auch, dass ich einen Thread habe, welcher die komplette Datenbankkommunikation betreibt. Wenn grad mal nix zu tun ist, dann schläft er halt. Bei mir ist allerdings alles komplett ereignisgesteuert, aber das steht ja hier nicht zum Thema. Warum sehe ich da bei Datenbanken die Notwendigkeit? Der Thread soll eine Verbindung zur Datenbank aufbauen. Und diese Verbindung soll über längere Zeiten (auch wenn grad keine Query o.ä. abgearbeitet wird) bestehen. Und wenn ich die Verbindung nicht unterbrechen will, kann ich auch nicht den Thread wegschmeißen. Dazu muss ich ihn halt schlafen legen. Warum will ich die Verbindung aufrecht erhalten. Z.B. wegen bestehenden Transaktionen (mit Rollback-Option). Oder bei Oracle-Packages wird je Session eine Instanz des "Package-Objektes" angelegt. Die Instanz benötige ich über längere Zeit. Dann gibt es noch Userverwaltungen, welche auf einer konstanten Verbindung zu Clients beruhen....

[Dezipaitor]

Sowas?
WaitForMultipleObjects(hAnyEvent, hThreadStopEvent, ... , YourTimeOut)