Jeder WINAPI-Aufruf ein SystemCall?

Der Aufruf welcher WINAPI-Funktionen verursacht eigentlich (implizit - für den Programmierer nicht sichtbar) einen 'System Call' mit Kontextwechsel in den Kernel-Prozess? Alle? Oder bei weitem nicht alle? Und wie sieht das mit Zeichenbefehlen über die GDI-API (insbesondere GetDC() hätte mich interessiert) aus?
Kann man es irgendwie anstellen, dass dieser Kontext-Wechsel vom User-Prozess in den Kernel-Prozess eher selten passiert, oder geschieht der ohnehin bei jeder C-Code-Zeile, also womöglich auch bei einfachen Zuweisungen wie a = 3?
Falls es allerdings WINAPI-Funktionen geben sollte, die nicht auch zwangsläufig einen Kontextwechsel verursachen: Woran erkenne ich das als Programmierer?
Stimmt es, dass die Laufzeit eines Programms sehr schlecht ist, wenn man sich zu oft (explizit/implizit) der System Calls (mit Kontextwechsel) bedient?

thx für Erläuterungen zu dem Thema.

Hi

Warum sollte es schlecht sein, wen man viel ein context-switch machen muss bzw. der Kernel. Wen es sein muss muss es sein, und sonnst halt nicht. Wo ist dein Problem?

Und bei jeder Zeile code Passiert das natürlich nicht. Wie von dir
dargestellt: a = 3, her bestimmt nicht. Wo macht er hier bitteschön ein context-switch?.

Das bestimmtst nicht du wen ein Contextswitch ausgelöst wird und wen nicht !Da bestimmt dein Kernel, anhand der Funktionen di er ausführen muss.

zbsp : http://www.linfo.org/context_switch.html

lowbyte

Ok so schlimm wird so ein System Call dann laufzeittechnisch wohl nicht sein. Hab das so auf diversen Seiten aufgeschnappt. Also alles nicht wahr. Und gut zu wissen, dass nicht jede C-Anweisung zu so einem Kontextwechsel führt. Habe schon befürchtet, dass bei so einem Kontext-Switch häufig der Stapelspeicher meines Programms aus dem Prozessor-Cache rausgeschmissen und später wieder hineingeladen wird. Man möchte ja meistens die Busbelastung zw. Hauptspeicher und Cache möglichst minimieren (laufzeittechnisch gesehen).
Thx für den Tipp

Hi

Klar braucht so ein Context-switch in den kernelmode seine Zeit. Aber was willst du dagegen tun wen du die Funktion (x) braucht, und dein kernel dan in den Kernelmode umschaltet ?! Nichts. Das ist einfach so. Aber es führen viele Wege nach "Rom", daher kannst du die Laufzeit sicher hier und da bei anderen Sachen beschleunignen.

lowbyte

Jochen Kalmbach

I.d.R. gilt: Alles was irgendwie eine Interaktion mit dem OS erfordert erfordert oft einen Kontext-Switch.
Wenn Du also Operationen hast, die keine Interaktion benötigen, dann hast Du auch keinen Context switch.
Aber es gibt natürlich auch sehr viel WinAPI Funktionen die natürlich *keine* Kontext Switch benötigen... dies ist aber oft nicht dokumentiert sondern das kannst Du nur durch Disassemblieren rausfinden.
Dokumentiert z.B: bei "SwitchToFiber" (das ist ja gerade der Vorteil von Fibers, dass ein Context-Switch in den Kernel beim Scheduling nicht notwendig ist... deswegen ist das auch so schnell...)

Mmacher

Als Faustregel kann man in etwa abschätzen:
* User-Mode Funktionsaufruf benötigt einige 100 Takte.
* Kernel-Mode Kontext-Switch benötigt einige 1000 (schlimmstenfalls sogar einige 10000) Takte.
Hier sieht man ganz offensichtlich daß ein Kernel-Mode Kontext-Switch deutlich ressourcenfressender ist.
(die Takte sind ohne reine Wartezeit beim suspend, und ohne die Zeit für die eigentliche Funktion selbst)

Was man/frau als guter Programmierer wissen sollte, ist es, daß es einige (viele ?) API-Funktionen (welche einen oder mehrere Kontext-Switches in den Kernel-Mode erfordern) durch sog. pure User-Mode Funktionen (oder andere schlankere Kernel-Funktionen) gleichwertig ersetzt werden können.

Die von mir am häufigsten gesehenen Beispiele von unnötigem Einsatz des Kernel-Mode Kontext-Switch Funktionen sind:
* Mutex (Kernel-Mode) statt Critical Section (deutlich schlanker), wenn nur innerhalb des Prozesses verwendet wird.
* Tastatur-Hooks (Kernel-Mode) statt WM_KEYDOWN/WM_KEYUP bzw. WM_CHAR (User-Mode)

Die Liste ließe sich sicher beliebig fortsetzen...

Martin

hustbaer

lowbyte_ schrieb:

Hi
Klar braucht so ein Context-switch in den kernelmode seine Zeit. Aber was willst du dagegen tun wen du die Funktion (x) braucht, und dein kernel dan in den Kernelmode umschaltet ?! Nichts. Das ist einfach so. Aber es führen viele Wege nach "Rom", daher kannst du die Laufzeit sicher hier und da bei anderen Sachen beschleunignen.

Also jetzt redest du ziemlichen Unsinn.

Natürlich ist es interessant zu wissen wo einen Kernelmode-Transition stattfindet.
Damit man die entsprechenden Funktionen seltener aufrufen kann z.B.
Oft kann man das ja sehr schön kontrollieren, z.B. kann man immer ReadFile() für ein einzelnes Byte aufrufen, oder man kann das Read-Buffering selbst übernhemen und grössere Stücke lesen.

lowbyte_

Ja das ist natürlich klar.! Glaube wir wissen worums geht !

lowbyte