Sleep(1)
-
Ne, wirklich sinnvoll ist das nicht. Nimm lieber einen Event, auf den du mit WaitForSingleObject() warten kannst.
-
net schrieb:
CodeFinder schrieb:
Ist das sinnvoll ?
nö, nicht wirklich. nimm besser 'WaitForSingleObject()' für solche verschnaufpausen...
Huh?!, Aber worauf soll ich denn dann warten...auf den Haupthread ?
-
CodeFinder schrieb:
Huh?!, Aber worauf soll ich denn dann warten...?
auf was du willst. guckst du CStoll's posting...
-
Hm ok, verstehe ... ist nur irgendwie mehr Aufwand, ...aber danke
.
-
CodeFinder schrieb:
net schrieb:
CodeFinder schrieb:
Ist das sinnvoll ?
nö, nicht wirklich. nimm besser 'WaitForSingleObject()' für solche verschnaufpausen...
Huh?!, Aber worauf soll ich denn dann warten...auf den Haupthread ?
Nein, auf einen Event, der ausgelöst wird, wenn der Nutzer den Pause-Modus beendet.
-
CStoll schrieb:
[...]Nein, auf einen Event, der ausgelöst wird, wenn der Nutzer den Pause-Modus beendet.
Jo und das wird im Hauptthread gesetzt, das meinte ich damit
.
-
Jochen Kalmbach schrieb:
PS: Ein Sleep/SwitchToThread macht i.d.R. fast nie Sinn. Synchronisationen sollte man immer über Events/Semaphore/Interlockes machen...
Jo, das ist mir schon klar, danke
Es gibt halt Fälle wo man - weils manchmal einfacher ist - interlocked variablen pollt. Und in so einer Schleife macht dann ein Sleep(1) schon Sinn... bei einem spin-sleep-lock ala critical section isses natürlich wurscht, da spinnt man ja eh nicht lange.
-
_msg schrieb:
Zitat:
Nö, Sleep(0) ist nicht böse.
Sleep ist vielleicht nicht böse - aber die häufige Verwendung dieser Funktion deutet zumindest auf Faulheit oder mangelnde Kenntnisse beim Programmieren hin. Sleep wird gerne eingesetzt, wenn Threads Ergebnisse pollen sollen und der Programmierer sich an Signalisierungsobjekte und Wartefunktionen nicht herantraut.Wer Threads und Signale sinnvoll einsetzt, benötigt kein Sleep.
---
CodeFinder schrieb:
Hm ok, verstehe ... ist nur irgendwie mehr Aufwand, ...aber danke
.q.e.d
-
@CodeFinder: Kannst Du Dich mal bei mir per Mail melden!?
-
-
CodeFinder schrieb:
Jochen Kalmbach schrieb:
@CodeFinder: Kannst Du Dich mal bei mir per Mail melden!?
Huh?!, why ?
Wird dann verraten wenn Du es machst
(ist aber nix schlimmes)
-
Jups habsch gemacht, hoffe sie ist angekommen.
-
Jochen Kalmbach schrieb:
hustbaer schrieb:
Von daher ist Sleep(0) an den Stellen wo man es üblicherweise findet (spinlock, polling) "böse" weil es Threads mit niedrigerer Priorität sämtliche CPU Zeit klaut.
Es ist nicht nur unsauberer Code, sondern wirklich böse!!!
Was man damit heraufbeschwört ist das sog. "Priority Inversion"!
http://en.wikipedia.org/wiki/Priority_inversionFolgendes Szenario:
Ein Thread mit Prio 11 wartet auf eine Resource (z.B. Event), welcher von einem Thread mit Prio 4 gerade gehalten wird.
Nun gibt es den Thread von "groovemaster" mit Prio 7, welcher ein "Sleep(0)" eingebaut hat und gerade anfängt zu laufen.
Was passiert:
Der Thread mit Prio 4 wird nie wieder drankommen und somit wird auch der Thread mit Prio 11 blokiert.
Fazit: Wir haben sozusagen einen "Dead-Lock", der von groovemaster verursacht wurde!(ok, das Windows-OS hat für einen solchen Fall im dnymaischen Prio-Bereich auch eine akzeptable Lösung... wer kennt sie?)
War vielleicht groovemaster an der Software-Entwicklung für den "Mars Pathfinder" beteiligt!? Da ist nämlich genau das passiert
Falls es noch wen interessiert (habs grad erst gelesen):
Für den von dir beschriebenen 'Dead-Lock' existiert unter NT-basierten Systemen ein Systemthread aus der Speicherverwaltung (kenne den unter der deutschen Bezeichnung 'Systemausgleichthread'
), welcher jede Sekunde prüft, ob ein Thread bereits seit mehr als 4 Sekunden nicht mehr an der Reihe war. Wenn er einen findet, setzt er die dynamische Priorität des betreffenden Threads auf einen höheren Wert (glaube auf 18). Aber das macht er pro Suchlauf nur bei maximal 10 Threads. Sollte es noch mehr davon geben, dann bricht er den Suchlauf ab um ihn eben eine Sekunde später an der gleichen Stelle fortzusetzen und weitere Threads aufzusuchen. Vielleicht nicht der Weisheit letzter Schluss,aber es funktioniert anscheinend ganz gut.grüsse
-
Mir ist jetzt (gestern) auch was passiert, müsste auch zum Thema passen:
Ein Programm von mir entpackt oggs, Dauer noch ca. 1 Stunde
Naja, damit es schneller geht, hab ich im Task-Manager die Prio des Prozesses (womit ja auch automatisch die Thread-Prio steigt) hochgehoben.Dachte erst, im Explorer geht nichts mehr (Prio Normal). Aber ging doch, nur etwas langsam... Reaktionszeit 4 Sekunden könnte hinkommen
Naja, jedenfalls ist es wohl, anders als ständig behauptet, nicht der Fall, dass Threads mit niedriger Priorität nie drankommen.
-
Badestrand schrieb:
Naja, jedenfalls ist es wohl, anders als ständig behauptet, nicht der Fall, dass Threads mit niedriger Priorität nie drankommen.
Das ist keine Entschuldigung mit diesem Sleep(0) Blödsinn anzufangen.
Das das OS so etwas abfängt zeigt nur das anscheinend genügend Programmierer solch einen Blödsinn machen...
Das Problem ist, dass durch so etwas zeitkritische Reaktionen eben nicht mehr möglich sind. 4 Sekunden ist ein Unding und das nur weil ein Programmierer dachte "Sleep(0) ist nicht böse"!
Wenn nun ein Prozess z.B. 50 Threads hat, die alle auf nette Ereignisse warten, dann dauert es nach Adam-Riese evtl. 20 Sekunden bis er mal wieder an die Reihe kommt...
-
@Badestarnd: Du hast das Problem nicht verstanden...
@vergessen: Du hast vergessen zu erwähnen, dass dies nur gemacht wird, wenn sich der Prozess im "normalen" Priority-Range ansiedelt (default).
-
Jochen Kalmbach schrieb:
@vergessen: Du hast vergessen zu erwähnen, dass dies nur gemacht wird, wenn sich der Prozess im "normalen" Priority-Range ansiedelt (default).
Äh. Sicher? *fürcht*
Was wenn ich nu nen HIGH_PRIORITY_CLASS Prozess laufen hab mit +1 und +2 Threads etc. - werden die dann nie geboostet?Ich kenn das nur so dass NT halt Threads die "lange nimmer dürfen haben" anfängt zufällig zu boosten...
Funktioniert auf jeden Fall gut, besser als die priority-inheritance Sache vom Win95 -- vor allem weil die NT Version auch mit selbstgebastelten Locks (die dann praktisch immer auf Events blocken, die ja keinen owner haben) funktioniert.
-
hustbaer schrieb:
Jochen Kalmbach schrieb:
@vergessen: Du hast vergessen zu erwähnen, dass dies nur gemacht wird, wenn sich der Prozess im "normalen" Priority-Range ansiedelt (default).
Äh. Sicher? *fürcht*
Was wenn ich nu nen HIGH_PRIORITY_CLASS Prozess laufen hab mit +1 und +2 Threads etc. - werden die dann nie geboostet?http://msdn2.microsoft.com/en-us/library/ms684828.aspx
The system does not boost the priority of threads with a base priority level between 16 and 31.
Also es Betrifft die "REALTIME_PRIORITY_CLASS":
http://msdn2.microsoft.com/en-us/library/ms685100.aspx
-
*schweiss abwisch*
Ok, das "wusste ich" (=irgendwann mal gelesen aber vergessen ).
Dann bin ich ja was beruhigt.
-
Jochen Kalmbach schrieb:
@Badestarnd: Du hast das Problem nicht verstanden...
Klar hab ich das Problem verstanden und ich finde die Diskussion um Sleep(0) auch sinnvoll, war mir ja selber nicht bewusst und kann ja anscheinend bei Halbwissen unangenehm werden.
Ich fande es aber nicht richtig, es so darzustellen, als dass manche Threads unter Umständen gar nicht mehr ausgeführt werden.
