Thread sur d'autres coeurs

Bonjour,

Je sais que c'est un sujet, qui est de nombreuses fois abordé. Mais je ne trouve pas de réponse clair.
J'ai un programme assez lourd en C++, sous Windows 7 sur visual studio 2010.
J'ai un programme "temps réel" (si l'on peut dire sous Windows 7 :lol
Ils répond à des contraintes temporelles à la ms, le soucis est que j'ai de nombreux Threads qui s’exécutent correctement dans les temps voulu.

Je reçois des horloges paliers externes de façon régulière que je ne dois jamais louper, ne pouvant faire des requêtes pour détecter les fronts bas de 4,3ms, j'ai donc un thread en polling de 3,3ms avec un Sleep(1) qui tourne en boucle et prend une bonne partie du temps d’exécution.
La deuxième, je la calcul de façon théorique avec le temps de propagation comme le scheduler passe son temps entre les threads des autres fonctions et celle de l'horloge qui est très chronophage.

Le programme fonctionne, mais ce n'est pas l'idéal. Je souhaiterais donc profiter de mes 8 cœurs en mettant les threads de détection de palier sur un autre cœur chacun. Ainsi le thread de l'horloge palier 1 ne prendrais pas la main tous les temps et je pourrais lire de façon réel la deuxième horloge de palier.

J'ai regardé OpenMP, mais apriori, je ne vois que des fonctions de parallélisation des calculs dans des boucles et autres qui ne m’intéressent pas.
J'ai essayé aussi avec SetThreadAffinityMask mais ça ne fonctionne pas comme je veux.

Je cherche depuis 2 jours sur internet sans succès. Soit ils proposent OpenMP, soit SetThreadAffinityMask(qui ne sert pas à ça, d'après ce que j'ai compris).

Donc si quelqu'un pourrais m'expliquer comment lancer mes Threads sur d'autres cœurs pour libérer mon pauvre scheduler qui a déjà trop de truc à essayer de faire "en même temps":oops:

Je ne vois comment votre programme peut fonctionner avec un "Sleep(1)" avec de telles contraintes temporelles.

L'attente active ne fait que peser sur le système.

Moi, je ne vois pas de corrections à votre solution (elle est un peu trop complexe pour ma tête de moineau).

Mais je pour des contraintes temporelles j'ai tendance à utiliser 2 autres solutions :
- Les timers multimédia
- Faire un driver Kernel.

Il doit avoir d'autres solutions, en fonction des contraintes du problème initial.

Comme j'ai dit le programme fonctionne parfaitement, mon dernier test me donne 999/1000 bon résultats sur le bon fonctionnement du programme. Le timer multimédia est déjà utilisé, pour des attentes de quelques ms. Mais contrairement au Sleep, il ne libère pas son tour dans le scheduler pour une autre tâche(ou sinon je vais changer de suite mon Sleep en timeSetEvent :P).
Mais oui l'attente active pèse énormément sur le système c'est bien le soucis. Le fait de faire un driver kernel à été abordé comme une des possibilités. Mais comme je n'en ai jamais fait non plus. Je me suis dit que si l'on pouvais parallélisé les threads ça résoudrait le problème tout en offrant de futur évolution du programme plus facilement :roll:
Tant qu'a faire une amélioration, autant que ce soit celle qui m'offre le plus de possibilité futur.
Si je ne trouve pas avant la fin de la semaine je me rabattrais sur le driver :?

Citation:

---

soit SetThreadAffinityMask(qui ne sert pas à ça, d'après ce que j'ai compris).

---

Je ne comprends pas pourquoi cette primitive ne correspond pas à votre solution, même si je pense que votre solution n'est pas forcement la bonne.

Faire un driver qui répond à des interruptions matériels, ça doit pas casser 3 pattes à un canard, en tout cas cela ne l'était pas avec les anciens modèles de drivers (ça fait un bout de temps que j'en ai pas fait).