R
hustbaer schrieb:
rapso schrieb:
was soll ein treiber denn auch anderes machen als entweder einen wait spin oder ein sleep aufrufen?
Der Treiber legt den Thread schlafen, und weckt ihn in einem Hardware-Interrupt wieder auf. (Genauer: im DPC, der im Interrupt-Handler angefordert wurde, kommt aber auf's selbe raus)
das ist kein echtzeit OS, ein interrput triggert sofort einen haendler, ja, aber diese sets nur einen thread auf aktiv, erst der scheduler wird diesen wieder rechenzeit geben. Das ist keine bessere granularitaet als ein sleep
windows arbeitet nunmal auf timeslice basis und es ist auch kein echtzeit OS, was der "system idle process" bekommt ist also in der granularitaet zwischen 10ms und 15ms auf dem default setting und wer will schon, dass ein treiber bei 16ms frametime bis 15ms ans OS abgibt?
Ja, das gilt so lange keine Threads über Interrupts aufgeweckt werden.
Deine Argumentation könnte man so auch auf 1000 andere Dinge anwenden. Wenn man das konsequent weiterdenkt, würde es bedeuten dass auch IO über SATA oder Ethernet mit "busy waiting" läuft, da die IOs viel weniger als 10ms dauern, und man ja keine Zeit verschenken will. Was definitiv nicht so ist.
obwohl seit WDM das viel weniger geworden ist (z.b. laufen die SATA IO ueber ein memory mapped bereich und der sata controller kuemmert sich selbst drum alles zu kopieren, es gibt nicht millionen interrupts/s damit man bei den winzigen caches trotzdem 500MB/s verschieben kann), kann es einen flip interrupt geben, aber genau so kann es ueber eine memory map laufen. ein device kann seinen "treiber-thread" schlafen legen bis ein interrupt kommt, dieser wird aber ebenfalls nur einen haendler aufrufen der den "treiber-thread" auf aktiv setzt.
du kannst dir vorstellen dass interrupt haendler in kritisch kurzer zeit ablaufen muessen und es ne menge davon geben kann, wenn einer zu lange laufen wuerde oder zu hohe priority hat, verschluckt das OS eventuell ankommende interrupts. Das soll nicht sein, und deswegen das umstaendliche system.
wenn du sound streams, kann es sein, dass es ein buffer swap noch als haendler gibt, der flagt dann aber den "mixer thread" den leeren buffer nachzufuellen, ich glaube nicht, dass ein aufwendiges mixen im haendler passieren wuerde.
Entsprechend weiss ich nicht, wie ein haendler der sofort zurueck kommen soll, mehr machen koennte als ein notify+active an einen wartenden driver thread vergibt. ich bezweifle ernsthaft, dass aus einem interrupt ein user-space thread anfaengt zu laufen, am scheduler vorbei, der ja die system time verteilen sollte.
