Endlosschleife in Thread?

BorisDieKlinge schrieb:

Ist das Intervall eines thread "Sleep(..);" auch von der priorität abhängig? D.h. umso kelienr die prorität, umso mehr ist die homogenität des gleichmäßigen intervall gestört oder?

Wer ist gestört?

http://de.wikipedia.org/wiki/Prozess-Scheduler
http://de.wikipedia.org/wiki/Thread_(Informatik)
...

Christoph

BorisDieKlinge schrieb:

Ist das Intervall eines thread "Sleep(..);" auch von der priorität abhängig? D.h. umso kelienr die prorität, umso mehr ist die homogenität des gleichmäßigen intervall gestört oder?

Auf "gleichmäßige Intervalle" darfst du dich beim Windows-Scheduler niemals verlassen. Solange du nicht durch Messungen festgestellt hast, dass du dadurch Performance verlierst, würde ich die Priorität eines Threads auch nicht ändern (außer in offensichtlichen Fällen). Dann kannst du einfach davon ausgehen, dass Threads einigermaßen gleichberechtigt parallel laufen. Das schlimmste was du machen kannst ist Annahmen über das zeitliche Verhalten verschiedener Threads zu machen.

BorisDieKlinge

würd ich jetzt bspw. 20 threads in meinem programm verwenden, und würde jeweils die höchste "Echtzeit" priorität einstellen, wäre windows sicher nur mit meinem progamm beschäftigt oder?

thordk

klar, die höchste prio nennt sich nicht ohne grund "echtzeit". ist zwar nicht wirklich echtzeit, aber zieht zumindest ca. 99% der resourcen

echtzeit heißt nur rechtzeitig

BorisDieKlinge schrieb:

würd ich jetzt bspw. 20 threads in meinem programm verwenden, und würde jeweils die höchste "Echtzeit" priorität einstellen, wäre windows sicher nur mit meinem progamm beschäftigt oder?

Nein. Erstens müßten die Threads ja auch tatsächlich etwas tuen. Solange ein Thread z.B. im Sleep ist bekommt er gar keine Rechenzeit zugewiesen, egal welche Prio er hat. Gleiches gilt für diverse Wait-states, z.B. warten auf input etc.

Zweitens gibt es zusätzlich Strategieen wie die Prio von niedrigen Thread jedesmal wenn sie "übergangen" werden hochzusetzen damit sie früher oder später auch mal "an die Reihe" kommen (wobei sie dann wieder auf ihre Ausgangsprio zurückgesetzt werden.

Prioritätsbasiertes Verfahren
Bei dieser Strategie wird jedem Prozess eine Priorität zugeordnet. Die Abarbeitung erfolgt dann in der Reihenfolge der Prioritäten. Da es sich dann (innerhalb der gleichen Prioritäten) um eine Strategie der Eingangsreihenfolge handelt, wird diesem Verfahren meistens noch ein Zeitscheibenverfahren untergeordnet, um trotzdem eine schnelle Antwortzeit zu ermöglichen. Zusätzlich wird in den verbreiteten Schedulern mit dynamischen Prioritäten gearbeitet, wobei sich die Priorität eines Prozesses mit der Zeit erhöht, damit auch niedrig priorisierte Prozesse irgendwann bearbeitet werden und nicht ständig von höher priorisierten Prozessen verdrängt werden.

(aus http://de.wikipedia.widearea.org/wiki/Scheduler)

Daher, so pauschal kannst Du 1000 Thread mit echtzeitprio anlegen, aber solange die z.B. alle nur im Sleep stehen passiert gar nix. Umgekehrt reicht shcon ein Thread mit folgender Schleife um Deinen Rechner in die Knie zu zwingen:

while(true);

Der Punkt ist aber, hat dieser Thread Echtzeitprio, dann "steht" Dein Rechner nahezu und alle anderen Threads reagieren extrem langsam bis gar nicht mehr. Hat der Thread dagegen eine sehr niedrige Prio, lastet er den Rechner zwar auch voll aus, alle andern Threads aber bekommen immer noch soviel Rechenzeit wie sie wollen und den System bleibt normal reaktiv.

In beiden Fällen aber ist die angezeigte Systemauslastung 100%.

Don06

BorisdieKlinge schrieb:

Wenn Programmabläufe und komplexe in Thread kapsle, bekommt mein Programm ja dadurch mehr Rechenzeit im allgemeinen!

Nö, du kannst nur zwei oder mehrere Dinge (pseudo-)parallel laufen lassen. Es ist also möglich, dass, während einer deiner Threads wartet, ein anderer weiter arbeitet. Ein einzelner Thread der nicht warten muss, hat genauso viel "Rechenzeit" wie deine ganzen Threads zusammen (sofern sie die gleiche Priorität haben).

Es kann dir sogar passieren, dass dein Programm durch den falschen Einsatz von Threads langsamer wird, weil Threads auf jeweils auf einen anderen warten und so nie viele gleichzeitig arbeiten können...

Gruß
Don06

thordk

hinweissz schrieb:

echtzeit heißt nur rechtzeitig

"nur" ist gut. denn genau das unterstützt windows nicht.

Jochen Kalmbach

BorisDieKlinge schrieb:

würd ich jetzt bspw. 20 threads in meinem programm verwenden, und würde jeweils die höchste "Echtzeit" priorität einstellen, wäre windows sicher nur mit meinem progamm beschäftigt oder?

Genau.
Wenn Du folgendes in einem Thread startest und so viele Threads davon machst, wie Du Prozessoren hast, dann kannst Du Windows nicht mehr bedienen... es bewegt sich dann nicht mehr die Maus (da zwar die ISR noch dran kommen, aber nicht mehr die DPC...)

SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
while(1)
  Sleep(0);

PS: Du musst natürlich Admin sein, sonst geht der Aufruf zu "SetPriorityClass" schief...

thordk schrieb:

hinweissz schrieb:

echtzeit heißt nur rechtzeitig

"nur" ist gut. denn genau das unterstützt windows nicht.

und wenn rechtzeitig in einer Woche ist?

BorisDieKlinge

@hinweissz: Naja du kannst den Thread ne woche warten lassen Sleep("NEWOCHE"); aber ob er dann genau nach der sleep an die reihe kommt ist fraglich......

Jochen Kalmbach

Wenn "1 Woche" als Echtzeit definiert wurde, dann ist es eben so.
Aber dann kann man 100000%ig davon ausgehen, das ich auch innerhalb der Woche dran komme!

Wird das jetzt wieder einer: "Wir erfinden absolut schwachsinnige Argumente nur um nicht zuzugeben das wir keine Ahnung haben"-Diskussion.

Im Zusammenhang mit Multitasking ist der Begriff Realtime (Echtzeit) eindeutig definiert:

In real-time systems, some waiting tasks are guaranteed to be given the CPU when an external event occurs. Real time systems are designed to control mechanical devices such as industrial robots, which require timely processing.

UNd genau das kann Windows (ohne zusätzliche Erweiterung) _nicht_

Jochen Kalmbach

skals schrieb:

UNd genau das kann Windows (ohne zusätzliche Erweiterung) _nicht_

Hat hier jemand wiedersprochen?

Eigentlich wollte ich nur sagen, dass Echtzeit nicht super schnell bedeutet.

Jochen Kalmbach schrieb:

skals schrieb:

UNd genau das kann Windows (ohne zusätzliche Erweiterung) _nicht_

Hat hier jemand wiedersprochen?

ich nicht. Das mit dem Windowskram wollte mir nur skals in den Mund legen.

Wo ist eigentlich diese Definition her? Das Echtzeit was mit "mechanical devices" zu tun haben muss, ist mir neu.

BorisDieKlinge schrieb:

@hinweissz: Naja du kannst den Thread ne woche warten lassen Sleep("NEWOCHE"); aber ob er dann genau nach der sleep an die reihe kommt ist fraglich......

Eine Antwort innerhalb einer Woche, hat nichts mit einer Woche schlafen zu tun

BorisDieKlinge

wenn ich die prioritätsklasse hoch setze, sind die changen höher, das der thread in "echtzeit" routiniert?? Ist zwar nich gewährleistet.. aber besser odre?

BorisDieKlinge schrieb:

wenn ich die prioritätsklasse hoch setze, sind die changen höher, das der thread in "echtzeit" routiniert?? Ist zwar nich gewährleistet.. aber besser odre?

Echtzeit hat erstmal nix mit Geschwindigkeit und super schnell zu tun. Das die unter Windows ihre höhste Priorität "echtzeit" nennen haben die halt gemacht weil es gut klingt.

BorisDieKlinge

ja ich mein ja nich superschnell, ich sage ja routiniert, in welchenn intervall ist ja egal!

Keine Ahnung was du mit routiniert meinst.
http://synonyme.woxikon.de/synonyme/routiniert.php
Dass ein Thread "routiniert" hat ich noch nie gehört.

thordk

keines der windows betriebssysteme (ohne erweiterungen) garantiert einem thread, dass er rechenleistung zugesprochen bekommt (übrigens auch keines der normalen *nix systeme), wenn er sie benötigt. es wird nur garantiert, dass der thread "irgendwann mal" wieder rechenzeit zugesprochen bekommt. aber er muss sich in einer warteschlange anstellen. und wenn vor ihm 50 threads rumrödeln, die grad nen kritischen abschnitt vorgaukeln, dann kommt der arme thread womöglich tatsächlich erst nächste woche dran

echte "echtzeit" ist für den otto-normal-entwickler auch gar nicht nötig. für den reichen die schwammigen zusagen der gewöhnlichen betriebssysteme völlig aus.