Sleep(1)

Jochen Kalmbach

groovemaster schrieb:

Wir reden hier aber schon über WinAPI und nicht Konsole, oder? Eine WinAPI Anwendung mit Sleep(0) hat jedenfalls keine 100% CPU Auslastung, da kannst du dich noch so quer stellen, das _ist_ so.

Dann solltest Du es ganz dringend mal ausprobieren... oder hier mal ein komplettes Beispiel posten!

Console oder WinApp spielt für den Scheduler keine Rolle... davon kennt der nix...

#include <windows.h>
#include <tchar.h>
int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
//int _tmain(void)
{
  while(true)
  {
    Sleep(0);
  }
}

groovemaster schrieb:

Alles was ich gesagt habe, ist, dass wer Sleep(1) verwendet, genauso gut Sleep(0) verwenden kann.

Und das ist absolut falsch, da die Änderung des Parameters von 0 auf >0 eine massiven Unterschied macht!
(Sleep(1) macht nämlich genau das was Du denkst, was Sleep(0) machen würde!)

hustbaer

@Jochen Kalmbach:
Wie siehts eigentlich mit SwitchToThread aus? Die Doku ist da ja nicht sonderlich klar, liest sich für mich aber so als ob da auch Threads mit niedrigerer Priorität drankommen würden.

Kann man SwitchToThread reinen Gewissens für Spinlocks verwenden?

Jochen Kalmbach

SwitchToThread hat prinzipiell den gleichen Effekt wie Sleep(0).

PS: Ein Sleep/SwitchToThread macht i.d.R. fast nie Sinn. Synchronisationen sollte man immer über Events/Semaphore/Interlockes machen...

CodeFinder

Sorry das ich mich da jetzt mal so 'reinschiebe', aber hab da auch mal ne kleine Frage...:
Ich verwende Sleep(n) (n mindestens > 100) um die Laufzeit meines Programms zuverbessern. Eini Thread meines Programms hat einen rechenintensiven Vorgang zu bewältigen, der sich vom Benutzer pausieren lässt, das ist so realisiert:

// ...
// in der Thread-Prozedur:
// ...
while(pThreadData->fPaused) // Variable ist volatile und wurde als Datenstruktur an den Thread übergeben (fPaused ist vom Typ bool)
   Sleep(100);
// ...

Ist das sinnvoll ? Damit dürfte doch mehr Rechenzeit für andere Prozesse/Threads zur Verfügung stehen, oder?

(Hab mir nicht den gesamten Forum-Thread durchgelesen. )

net 0

CodeFinder schrieb:

Ist das sinnvoll ?

nö, nicht wirklich. nimm besser 'WaitForSingleObject()' für solche verschnaufpausen...

CStoll

Ne, wirklich sinnvoll ist das nicht. Nimm lieber einen Event, auf den du mit WaitForSingleObject() warten kannst.

CodeFinder

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 ?

net 0

CodeFinder schrieb:

Huh?!, Aber worauf soll ich denn dann warten...?

auf was du willst. guckst du CStoll's posting...

CodeFinder

Hm ok, verstehe ... ist nur irgendwie mehr Aufwand, ...aber danke .

CStoll

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.

CodeFinder

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 .

hustbaer

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

Jochen Kalmbach

@CodeFinder: Kannst Du Dich mal bei mir per Mail melden!?

CodeFinder

Jochen Kalmbach schrieb:

@CodeFinder: Kannst Du Dich mal bei mir per Mail melden!?

Huh?!, why ?

Jochen Kalmbach

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)

CodeFinder

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_inversion

Folgendes 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

Badestrand

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.

Martin Richter

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...