Bonjour, j'ai un programe multithread sur une machine multiprocesseurs et je souhaiterais savoir comment récupérer le processeur (numero du processeur et non son type) sur lequel s'exécute le code qu'il y a dans un thread.  
Si vous avez une méthode simple sous windows XP, je suis preneur. Merci

Si sous windows, cpuid, smbios, WMI, fonction recherche du forum

Tu es sur que ce n'est pas pour récuppérer les caractéruistiques du processeur ce que tu proposes?

tu veux parler du serial du proc ?

Bon on va faire simple:  j'ai 2 processeurs sur ma machine et je veux savoir si mon thread s'exécute sur le processeur 1 ou sur le processeur 2.

GetCurrentProcessorNumber

Ouep c'est exactement ça que je cherche. Sauf que ça existe pas sous windows xp. Bon je cherche dans cette direction, on s'approche.

En fait ca existe sous .net depuis le 1.1 si je ne m'abuse, donc dispo sous .net.

ok on doit pouvoir avec cpuid en regardant le processeur actif. Une fonction comme GetCurrentProcessorNumber() aurait été plus simple mais bon ...

Autre solution SetThreadIdealProcessor, tu force un thread a s'exécuter sur une cpu donnée.

Merci mais le but était plutot de contrôler que l'os distribue bien mes threads sur des processeurs différent.

 
Je ne vois pas la raison qui l'empêcherait de le faire, sauf si tu t'es raté dans la synchro et que tes threads ne tournent jamais en même temps. Est-ce possible de mettre une grosse boucle de calcul au milieu et d'en lancer plusieurs (2 suffisent) ? Tu regardes ensuite l'occupation CPU (par contre sous Windows je ne sais pas si le gestionnaire de tâches différencie les CPU) et tu devrais assez vite être convaincu que ça marche.
 

 
Et pourquoi il le ferait (ou ne le ferait pas d'ailleur) pour ce genre de gestion il vaut mieux faire confiance à l'OS.
 
Ca dépend du contexte par exemple si sur la 2eme cpu il y a un gros process  
bien gourmand ou serait l'intéret de ventiller des threads sur une cpu au taquet ?

Oui je suis d'accord que c'est l'os qui doit ventiler les threads. Mon contexte est : une application doit traiter une tache les plus vite possible sur une machine bi proc. C'est la seule application qui tourne. Dans ce cas, je m'attend à voir les treads ventilés sur les 2 cpu. J'aurais préféré valider de façon un peu plus propre que de regarder dans le gestionnaire des taches mais bon on va s'en contenter.  
Merci à tous!

SetThreadIdealProcessor ne force pas une thread à s'executer sur un cpu/core particulier, c'est seulement une indication. Pas plus d'ailleurs que cpuid ne retourne de numero logique puisque celà n'a pas de sens localement mais seulement au niveau de l'OS.
 
Pour effectivement forcer l'execution sur un cpu/core/noeud - ou plusieurs - il faut toucher le masque d'affinité, cf SetProcessAffinityMask/SetThreadAffinityMask. Notons qu'xp n'est que partiellement NUMA-aware, neanmoins les allocations, par exemple via VirtualAlloc, serons affectées; la localité de la mémoire est une excellente raison pour tripoter le masque d'affinité. Et puis ce n'est pas comme si le scheduler de windows était un modele du genre: il a une facheuse et lamentable tendance au pingpong.
 
PS: les k8 (athlon64 & co) utilisent un modèle NUMA et non un basique SMP comme les Intel, ce qui n'est pas sans consequences.