Realtime Thread



  • Hallo zusammen,

    ich schreibe im Moment an einer Audio-App, welche alle 11 ms einen Audioframe bekommt und diesen verarbeiten muss. Die Anwendung soll auf WinXp laufen.

    Nun zu meiner Frage:

    Wieviel Realtime steckt hinter einem RT-WinXp-Prozess?
    Werden noch andere Prozesse gescheduled?

    Gruß && Danke



  • Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • In der MSDN findest du eigentlich alle Infos. Ein Process mit Realtime-Priorität hat Vorrang vor allen Prozessen und vor Interrupt Service Routinen. Daher sollte man das nur mit Vorsicht verwenden, da eventuell deine Maus nicht mehr reagiert, oder Caches nicht weggeschrieben werden.



  • Falsch. Ein Prozess hat niemals vorrang vor ISRs, und soweit ich weiss nichtmal for DPCs.



  • So steht in der Doku. Und bei richtigen Echtzeitbetriebssystemen wie QNC ist das ganz sicher so. Ein Endlosschleife in einem Prozess mit der höchsten Priorität lässt das ganze System zusammenbrechen.



  • Nein, es steht nicht so in der Doku, und es geht hier um Windows und nicht um QNX.
    Ich kann nix dafür dass du anscheinend die Doku falsch interpretierst, ISRs laufen auf jeden Fall weiter, egal wie hoch die Priorität eines Prozesses ist.



  • Also, ich muss "e_Gute_Fee" ein stück weit recht geben...
    Ein Prozess mit Prio 31 hat natürlich niemals vorrang vor ISRs aber natürlich vor allen anderen Dingen (und dazu gehören auch DPCs).
    In Windows gibt es keine Unterscheidung zwischen Kernel- und User-Mode-Threads. Wenn somit ein User-Mode-Thread mit Prio 31 läuft, dann ist dies die höchste Prio was der Scheduler kann. Es gibt keine höhere Prio mehr (nur noch ISRs, die aber "asynchron" laufen).
    Also, um es zu verdeutlichen:
    Wenn Du *einen* Prozessor hast und erzeugst einen User-Mode-Thread mit Prio 31 und lässt diesen in einer Endlosschleife laufen, dann bleibt Dir nichts anderes ürbig als den Reset-Knopf zu drücken.
    Es werden weder die DPCs der Maus/Tastatur ausgeführt noch irgendwas auf dem Bildschirm gezeichnet.

    Somit: Gaaaaanz vorsichtig sein mit Prio 31!

    PS: Und es hilft natürlich nicht viel, wenn die ISRs laufen aber die dazugehörigen DPCs nicht mehr 😉



  • @Jochen: bist du sicher? Normale Threads laufen mit PASSIVE_LEVEL, DPCs laufen mit DISPATCH_LEVEL, müssten also jeden normalen Thread unterbrechen, egal was dieser für eine Thread-Priorität hat.
    In der Doku (DDK, "Writing an ISR") steht zumindest:

    If the driver has a DpcForIsr routine, call IoRequestDpc with pointers to the current IRP, the target device object, and the saved context. IoRequestDpc queues the DpcForIsr routine to be run as soon as IRQL falls below DISPATCH_LEVEL on a processor.

    Es wird auch an anderen Stellen immer wieder erwähnt dass DPCs jeden normalen Thread unterbrechen, zumindest solange dieser gerade Usermode Code ausführt.

    Andrerseits habe ich selbst erlebt dass oft die einfachsten Dinge dazu führen können dass DPCs stark verzögert werden, z.B. reicht es oft schon calc.exe aufzumachen, 123456789 einzutippen und dann auf "n!" zu drücken. Und calc.exe läuft dabei sicher nicht mit REALTIME_PRIORITY_CLASS.

    Hm...



  • Ich muss sagen: mit DPCs bin ich mir nicht 100%ig sicher...
    Aber der effekt bleibt der gleiche: Ein

    while(1);
    

    in einem Thread mit Prio 31 führt auf einem 1-Rechner-System zum "Absturz" (hängenbleiben).
    Natürlich kannst Du das auch auf einem Mehr-Rechner-System machen, indem Du einfach so viele solcher Threads erzeugst wie Du logische Prozessoren hast 😉

    PS: Nein, das ist keine Sicherheitslücke, da man Threads mit Prio 31 nur als Admin erstellen kann!



  • Jochen Kalmbach schrieb:

    Ich muss sagen: mit DPCs bin ich mir nicht 100%ig sicher...

    threads kommen erst wieder dran, wenn die DPC queue leer ist.
    🙂


Anmelden zum Antworten