Multithreading et attribution aux processeurs/coeurs

Bonjour à tous,

Une question, peut-être naïve, quant au multithreading sur unités multi-processeurs/cores.

Je fais tourner, en parallèle de ma boucle principale qui effectue des calculs intensifs, un fil d'exécution qui nécessite beaucoup moins de ressources processeurs, mais qui doit réagir en toute circonstance. En gros, il est appelé toutes les 100 millisecondes par un appareil extérieur, et s'il n'est pas disponible à ce moment-là (typique quand l'autre fil bloque tout le processeur), tout plante. Tout ceci sous Linux, sur un processeur QuadCore, en utilisant <pthread>.

Pour éviter ce genre de plantages, j'ai essayé de réflèchir à une priorisation du thread léger par rapport à la boucle principale, mais je crois que cela n'est possible qu'entre deux threads.

D'où une idée : et si les deux parties de mon programme tournaient chacune sur un coeur préattribué du processeur, est-ce que ça ne règlerait pas le problème ?
D'où une interrogation : est-il possible d'attribuer aux threads créés un coeur dédié d'exécution, sur lequels ils tournent exclusivement ? Si non, avez-vous une idée pour résoudre ce problème ?

Merci à tous ceux qui prendront le temps d'illuminer mon lampion... ;)

Pour autant que je sache( a verifier donc), seul l'OS est a même de decider quel thread tourne sur quel proc.

Par contre, va voir du coté de la priorité des threads, qu'i est peut etre possible d'utiliser avec les pthreads ( la aussi, pas sur >.< ).

Dans les extentions de Pthread pour HP-UX il y a cette possibilité d'affecter des threads à chaque proc.

Il est possible que de telles extentions existent pour Linux, mais cela n'est valable que si ton application marche sur une machine dédiée, que se passera-t-il qaund d'autres applications gourmandes tourneront sur la même machine ?

Logiquement l'OS doit repartir les threads au mieux, il fau lui faire confiance...

Citation:

---

Envoyé par Gandalf

mais cela n'est valable que si ton application marche sur une machine dédiée, que se passera-t-il qaund d'autres applications gourmandes tourneront sur la même machine ?

---

En général, quand on est relié à un appareil extérieur, on est sur une machine dédiée, et on contrôle les process présents.

Avec pthread, aucune idée sur l'éventuelle façon de contrôler la répartition des threads.

Avec les API de multithreading de Win32, tu peux (SetThreadIdealProcessor() etc.)

Je rebondis sur ce thread en posant une question

Quel intérêt peut il y avoir à dire que tel thread doit tourner (ou plutôt préférerait) tourner sur tel processeur et pas sur un autre.

Il doit bien y avoir un intérêt car sinon les fonctions SetThreadAffinityMask(), GetThreadAffinityMask() et SetThreadIdealProcessor() dans l'environnement Microsoft n'existeraient pas.

Je dirais faciliter la reprise, pour t'assurer qu'ils soient toujours répartis indépendamment du reste de la consommation, ou mettre deux threads sur le même si tu sais qu'ils ne sont pas activés en même temps, etc.

Sous linux il y a aussi nice ?

Ce n'est pas tout à fait le même but

La commande Linux/Unix "nice" permet de changer (si possible) la priorité d'un processus. Elle ne permet pas de choisir sa CPU.

Citation:

---

Envoyé par ram_0000

Ce n'est pas tout à fait le même but

La commande Linux/Unix "nice" permet de changer (si possible) la priorité d'un processus. Elle ne permet pas de choisir sa CPU.

---

En même temps choisir sa CPU sa demande quand même une certaine connaissance pour savoir ce qu'on fait, l'os est plus à même d'optimiser cela.

Merci pour vos réponses ; l'intérêt, de mon point de vue, qu'il y a à séparer les deux tâches entre les processeurs est qu'on évite des problèmes éventuels de priorités mal gérées. Chaque thread peut reprendre la main aussi rapidement qu'il le veut, sans que les autres ne le perturbent.

Ceci étant, il semble à lire vos réponses qu'il n'y a pas de solution facile pour faire ceci. Je vais donc sans doute essayer de trouver une alternative ; sans doute à base de priorités. A tout les coups, de toute façon, le problème ne vient pas de là où je l'imagine...

Tût tût wuuuu... Gzzzbritz. Biiiiiiiiiiiip