Sur Win32, comment déplacez-vous un thread vers un autre core CPU?

Question

Je voudrais m'assurer qu'un thread est déplacé vers un noyau de CPU spécifique et ne peut jamais être déplacé par le programmateur.

Il y a un appel SetThreadAffinityMask() mais il n'y a pas GetThreadAffinityMask().

La raison pour laquelle j'en ai besoin est que les temporisateurs à haute résolution seront désordonnés si le planificateur déplace ce thread vers un autre processeur.

Answer 1

Vous devriez probablement utiliser SetThreadAffinityMask et espérer que cela fonctionne.

MSDN

Answer 2

Que dit Ken. Mais si vous ne croyez pas que cela fonctionne, vous pouvez appeler à nouveau SetThreadAffinityMask et confirmer que la valeur de retour correspond à ce que vous attendez du masque. (Mais bien sûr, si vous ne faites pas confiance à la fonction, vous ne pouvez pas faire confiance au second appel ...)

Ne soyez pas déroutés par l'existence de GetProcessAffinityMask. Cette fonction n'est pas là pour vérifier que SetProcessAffinityMask a fonctionné, mais par ex. Ainsi, vous pouvez construire une affinité de thread qui est un sous-ensemble d'affinité de processus.

Il suffit de regarder que la valeur de retour et de vérifier que ce n'est pas 0 et vous devriez aller bien.

Answer 3

Vous n'avez pas besoin de Get Thread AffinityMask. Obtenez simplement la valeur de Get Processus AffinityMask, désactivez certains bits, puis appelez SetThreadAffinityMask. Les threads héritent du masque d'affinité du processus, et puisque leur affinité est sous votre contrôle, vous connaissez déjà le masque d'affinité d'un thread (c'est celui que vous avez défini).

Answer 4

Si vous pouviez appeler une fonction qui renvoie un nombre indiquant la CPU sur laquelle le thread s'exécute, sans utiliser l'affinité, la réponse serait souvent erronée dès que la fonction est retournée. Donc, vérifier le masque retourné par SetThreadAffinityMask() est aussi proche que vous allez l'obtenir, en dehors du code du noyau tournant à l'IRQL élevé, et even that's changing.

Il semble que vous essayez de contourner les problèmes de décalage d'horloge RDTSC. Si vous utilisez l'instruction RDTSC directement, envisagez d'appeler QueryPerformanceCounter() à la place:

• QueryPerformanceCounter() sur Windows Vista utilise le HPET si elle est prise en charge par le chipset et dans les tables ACPI du système.
• Les systèmes basés sur AMD utilisant le AMD Processor Driver compenseront la plupart du temps l'asymétrie d'horloge multi-noyau si vous appelez QueryPerformanceCounter(), mais cela ne fait rien pour les applications qui utilisent directement RDTSC. Le AMD Dual-Core Optimizer est un hack pour les applications qui utilisent RDTSC directement, mais si le décalage de l'horloge change en raison d'une rampe d'horloge C1 (où la vitesse d'horloge est réduite dans l'état d'alimentation C1), vous aurez toujours un décalage d'horloge. Et ces utilitaires ne sont probablement pas très répandus, donc l'utilisation de l'affinité avec QueryPerformanceCounter() est toujours une bonne idée.