Zitat von
Olli:
Das stimmt nicht so ganz, denn ob es dir gefällt oder nicht, der Scheduler schert sich recht wenig darum was ein Usermode-Thread mal eben möchte. Die werden sozusagen in der Freizeit - dann allerdings mit gegebener Priorität - abgearbeitet. Einen echten Boost für einen Thread kann nur ein Treiber garantieren - und selbst dann haben wir mit Windows ja noch kein Echtzeitsystem. "Starving threads" sind also durchaus möglich und können vom System nicht verhindert werden, wenn ein Thread im Kernelmode die CPU-Ressourcen an sich reißt.
Was willst du uns damit jetzt sagen? Hat jedenfalls nichts direkt damit zu tun. Es ist doch völlig normal (auch bei singlecore-cpu), das windows letzendlich selbst entscheidet welcher Thread eine höhere priorität bekommt.
Zitat von
Olli:
Übrigens finde ich dein Beispiel nicht sehr gelungen. Durch die Angabe von 1 und 2 im Zusammenhang mit Core #1 bzw. Core #2 respektive, erweckst du den Anschein es handele sich um eine Aufzählung. Du solltest klarstellen daß es eine Bitmaske ist. Im Übrigen wäre die Aufzählung der CPUs/Kerne korrekt: Core #0 und Core #1 respektive.
Ja stimmt das wollte ich vor einiger Zeit schonmal ändern, aber ich hab leider keinen Zugriff auf meinen Beitrag in der CodeLibrary.
Zitat von
Olli:
Abgesehen davon mißachtet dein Beispiel folgende Warnung:
Zitat:
A thread affinity mask must be a proper subset of the process affinity mask for the containing process of a thread. A thread is only allowed to run on the processors its process is allowed to run on.
In meiner function wird nichts mißachtet, in dem Fall gibt meine function den Wert "False" zurück!
mfg