Sleep(1)

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

Badestrand

hustbaer schrieb:

Indem du einfach ganz normale blocking IO Calls verwendest, also ReadFile ohne OVERLAPPED?

Nightstorm schrieb:

Würde ich gerne, ist aber von Linux vorgegeben

Gibts unter Linux nichts äquivalentes? Hab immer das Gefühl, dass sich viele Sachen unter Windows und Linux ähnlich behandeln lassen (jdnfalls mit den selben Mechanismen/Prinzipien)?

hustbaer

Wieso jetzt Linux hier, das ist das WinAPI Forum *verwirrt-sei*. Und klar gibts unter Linux blocking IO. Und wo es kein blocking IO gibt gibts ganz sicher was äquivalentes zu completion Ports. Darf ja auch ne normale Callback Funktion sein, wurscht, auf jeden Fall muss man nicht pollen.
Auf Pollen sind nämlich viele allergisch, huch, welch Wortwitz

Macht ausserdem wenig Sinn eine Linux Frage in diesem Thread zu stellen, da Sleep(0) unter Linux nicht notwendigerweise das selbe macht wie unter Windows, wobei ich fast davon ausgehe dass die entsprechende Funktion dort (Linux) anders heisst.