Zitat von
negaH:
Die einzigste zeitkritische Operation ist wenn man RDTSC und QueryPerformanceCounter aufruft. Sollte exakt dazwischen ein Taskswitch auftreten haben wir eine Messungenauigkeit. Man könnte das mit einer höheren Threadpriorität versuchen, ist aber im Grunde sinnlos
Der Taskswitch könnte ja zu einem ähnlich priorisiertem Task erfolgen, ergo mit höherer Priorität verhindert man nicht den Switch.
Da kann dir der nächste "nette" Treiber schon ein Schnippchen schlagen. Die Threadprioritäten haben zwar zur Errechnung des Thread-Quantums eine Bewandnis, aber das juckt mal nen Treiber oder dessen DPC oder ISR garnix. Dein Usermode-Code läuft eben mal nur auf IRQL PASSIVE_LEVEL und im Falle eines APCs ein Level höher, aber diese beiden sind, wie man so schön sagt, unterbrechbar. Kommt also Code mit einem höheren IRQL (nicht verwechseln mit IRQs!!!), wird dein Code mal eben angehalten bis der andere fertig hat
(Das wären bspw. Geräte-IRQLs - auch nicht zu verwechseln mit IRQs - wo dann die ISRs - Interrupt Service Routines - laufen, siehe dein Kommentar zu CLI/STI.)
Zitat von
negaH:
Denn im Grunde müsste man wirklich in den Kernelmodus um per CLI/STI auch IRQs unterdrücken zu können. wie's Olliver schon sagte.
Naja, Spinlock halten reicht schon, weil da nix anderes in dem Moment "ran darf". Ist dann halt bloß auf einem Prozessor und du darfst keinen ausgelagerten Speicher "anfassen" - ansonsten sagt dir Windows im stilisch ansprechenden himmelblauen Look: KMODE_EXCEPTION_NOT_HANDLED oder KERNEL_MODE_EXCEPTION_NOT_HANDLED oder (am wahrscheinlichsten) der allseits beliebte IRQL_NOT_LESS_OR_EQUAL.
Nachtrag: Übrigens, wenn ich mal Zeit finde, könnten wir das mal versuchen. Mich interessiert das eigentlich mal von der Seite her inwieweit das machbar ist. Man könnte ja eine ISR für die Tastatur einrichten, die dann den Treiber ggf. unterbrechen darf.