4. Sleep(1)

Sleep(1)

  • C

    Jochen Kalmbach schrieb:

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

    Huh?!, why ?

    0
  • J

    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)

    0
  • C

    Jups habsch gemacht, hoffe sie ist angekommen.

    0
  • ?

    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

    0
  • B

    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.

    0
  • Mod

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

    0
  • J

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

    0

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

    0
  • J

    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

    0

  • *schweiss abwisch*
    Ok, das "wusste ich" (=irgendwann mal gelesen aber vergessen 😉 ).
    Dann bin ich ja was beruhigt.

    0
  • B

    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.

    0

  • Ich fande es aber nicht richtig, es so darzustellen, als dass manche Threads unter Umständen gar nicht mehr ausgeführt werden.

    Ist aber so 😉
    z.B. wie Jochen uns gerade wissen liess wenn der Thread wo immer bloss "Sleep(0)" macht einem Prozess mit REALTIME_PRIORITY_CLASS gehört.

    Und wenn man schon "böse" sein will, dann geht das mit SetThreadPriority() in einer Schleife viel viel effektiver 😃

    0
  • ?

    Jochen Kalmbach schrieb:

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

    ja, man hätte expliziter erwähnen sollen,dass dieser Systemthread nur für den dynamischen Bereich zwischen den Prioritätsstufen 0-15 (nicht 18 *Hust*) - wie dann von dir beschrieben - gilt, wo ja eh die meisten normalen Programme laufen (sollten).
    Die 'Echtzeit'-Prioritäten (dann zwischen 16-31) hebt oder senkt Windows niemals von sich aus. Die sind dann sozusagen statisch. Aber diese Prioritäten werden meist eh nur von wichtigen Systemthreads oder Treibern benutzt bzw. von Programmen wo es Sinn macht. (Zumindest meistens 🙂 )

    grüsse

    0
  • J

    hustbaer schrieb:

    z.B. wie Jochen uns gerade wissen liess wenn der Thread wo immer bloss "Sleep(0)" macht einem Prozess mit REALTIME_PRIORITY_CLASS gehört.

    Wenn Du nur einen Prozessor hast und machst ein:

    #include <windows.h>
#include <tchar.h>
int _tmain(void)
{
  SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
  SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
  while(true)
    Sleep(0);
}

    Dann darfst Du drei mal Raten ob Du anschliessend ohne den "Reset-Taster" zu betätigen das Programm beenden kannst 😉

    PS: Wenn Du zwei oder mehr Prozessoren hast musst Du den Prozess halt so viel mal starten, wie Du Prozessoren hast 😉

    0
  • ?

    Jochen Kalmbach schrieb:

    PS: Wenn Du zwei oder mehr Prozessoren hast musst Du den Prozess halt so viel mal starten, wie Du Prozessoren hast 😉

    Oder man benutzt SetProcessAffinityMask

    0
  • J

    vergessen schrieb:

    Oder man benutzt SetProcessAffinityMask

    Was soll das bringen???

    0
  • ?

    War nur ne kleine und allgemeine Anmerkung auf Mehrprozessorsysteme.Wenn das Progg dann mit mehreren Threads überall auslasten soll.Aber wurscht.

    Fehlte allerdings noch SetThreadAffinityMask.

    0
  • J

    vergessen schrieb:

    War nur ne kleine und allgemeine Anmerkung auf Mehrprozessorsysteme.Wenn das Progg dann mit mehreren Threads überall auslasten soll.Aber wurscht.

    Wenn es "Auslasten soll", dann machst Du am besten gar nichts!!!
    Mit den genannten Funktionen kannst Du nur was an Deinem Prozess einschränken. Also immer nur weniger Rechenzeit bekommen, aber nie mehr...

    0
  • ?

    Jochen Kalmbach schrieb:

    vergessen schrieb:

    War nur ne kleine und allgemeine Anmerkung auf Mehrprozessorsysteme.Wenn das Progg dann mit mehreren Threads überall auslasten soll.Aber wurscht.

    Wenn es "Auslasten soll", dann machst Du am besten gar nichts!!!
    Mit den genannten Funktionen kannst Du nur was an Deinem Prozess einschränken. Also immer nur weniger Rechenzeit bekommen, aber nie mehr...

    ahja! Na, wenn du das sagst...

    0
  • ?

    mir fällt dabei auch wieder ein, warum ich hier meinen Nutzernamen vergessen hatte 😃

    0
Anmelden zum Antworten