Sleep(1)

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

Jochen Kalmbach

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

hustbaer

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.

Jochen Kalmbach

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

hustbaer

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

Badestrand

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.

hustbaer

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

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

Jochen Kalmbach

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

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

Jochen Kalmbach

vergessen schrieb:

Oder man benutzt SetProcessAffinityMask

Was soll das bringen???

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.

Jochen Kalmbach

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

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

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

Nightstorm

schuldigung, das ich mich hier so einfach einklinke.

Aber ich schreibe gerade an einer DLL, die 2 Threads beinhaltet. Der eine mit Sleep(500) sollte nicht problematisch sein. Aber mein IO-Thread muss im millisekunden Takt am USB-Bus horchen. Wie genau stellt ihr euch das ohne Sleep(0) vor? Ich bräuchte da etwas völlig Signal unabhängiges, da dieser Thread IMMER pollt.

Jochen Kalmbach

Windows ist auch nach 60 Beiträgen noch kein Echtzeit OS.
Warum willst Du den "pollen"??? Stell Dein System auf einen vernünftigen Event-Mechanismus um!

Nightstorm

Würde ich gerne, ist aber von Linux vorgegeben. Danke. das mit dem keine Echtzeit, lag mir auch im Kopf. Danke

hustbaer

Aber mein IO-Thread muss im millisekunden Takt am USB-Bus horchen. Wie genau stellt ihr euch das ohne Sleep(0) vor?

Indem du einfach ganz normale blocking IO Calls verwendest, also ReadFile ohne OVERLAPPED? Irgendwie verstehe ich das Problem nicht, vielleicht kannst du es etwas genauer beschreiben - also was du machst und wieso du dich gezwungen siehst Sleep(0) zu verwenden...