Thread, sleep et yield

Bonjour à tous,

j'ai un soft fait de blocs et d'un scheduler.
Chaque bloc a un thread propre avec une boucle de traitement du type:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

while(run) { boost::mutex::scoped_lock lock(*InMutex); si nouvelles données - Gestion des données arrivantes: lock.unlock()   boost::mutex::scoped_lock lock2(*OutMutex); si données générées - Gestion des données sortantes... lock2.unlock()   boost::this_thread::sleep(boost::posix_time::microseconds(idlePeriod_us));   }

---

(PS: idlePeriod_us = 0).

Le scheduler a aussi son thread propre qui a pour tache de faire passer les infos de blocs en blocs avec le même système de boucle. Les Mutex permettent d'éviter les accès simultanées aux données entrantes ou sortantes par les blocs et le scheduler.

Le logiciel tourne bien sur mon PC XP. C'est-à-dire que le flux de données entrants est bien traité en temps réel.
Je l'ai compilé sous 7, et un retard de traitement apparait dans le flux. En cherchant un peu, j'ai remplacé la ligne (pour chaque thread):
boost::this_thread::sleep(boost::posix_time::microseconds(idlePeriod_us));
par
boost::this_thread::yield();
et le retard dans la gestion du flux a disparu.

Le problème c'est que j'ai maintenant un 3e PC (sous XP SP3), et j'ai à nouveau le même problème de latence/retard dans la gestion de mon flux de données.

Est ce que quelqu'un a une idée de l'origine du problème ? Ou de solution. J'ai vu des techniques avancées avec des conditions d'attente. Est ce que cela pourrait arranger le problème ?

Merci !

C'est quoi le rôle de ce sleep ? Généralement, quand je vois ça dans le code, c'est qu'il a un problème.

Le rôle de sleep c'est de permettre au thread de rendre la main à windows

Pour quoi faire ? Si tu as des contraintes de traitement sur tes calculs, il vaut mieux généralement les effectuer dans un thread qui n'a rien de graphique, et avoir un autre thread qui lui effectue tout ce qui est affichage. Le thread de calcul n'a jamais besoin de "rendre la main à windows"

Tu ne devrais pas constater de différence intrasèque entre thread::yield et thread::sleep(0) sous windows, étant donné que thread::yield est implémenté par un thread::detail::sleep(0) sous windows. De manière générale, quand on veut rentre la main au système, la bonne fonction a utilisé est "yield".

Ensuite, il faut comprendre que yield rend la main au scheduler system, pas à ton scheduler, donc il peut se passer plein de choses dépendant de l'implémentation du scheduler système.

Il est difficile de dire d'où vient le problème sans savoir ce que fait reellement ton "scheduler", comment il donne la main à un thread X de traitement. Les condition variables ne sont pas je dirai une technique avancée mais une technique de base pour signifier à un thread de ne se déclencher que sous certaines conditions (l'avantage c'est que le scheduler systeme en général comprend ça (ça dépend de l'implémentation du système de thread toutefois) (il comprend en 1:1 ou en N:M)).

Que fais réellement le scheduler ? (vu qu'il n'a pas l'air de choisir activement quelle thread executer, ni de garantir qu'un thread puisse accéder tranquillement aux ressources qui lui sont nécessaires) Faites-vous vraiment des calculs aux parallèles au final ?

Le scheduler passe le flux de données de blocs en blocs. Il effectue la boucle de traitement suivante:
- si données en sortie d'un bloc, lecture de ces données et copie vers le bloc suivant.
Et ceci pour chaque "lien" entre les blocs.

Il fait ceci "en permanence" et si aucune données n'est "transférable", il reboucle après avoir attendu.

J'ai trouvé un tutorial http://www.brainbell.com/tutorials/C...om_Another.htm ou l'auteur est d'accord avec votre propos de dire qu'il est préférable d'avoir un scheduler qui s'occupe de réveiller les bons threads au bon moment plutôt que d'avoir des threads qui scrutent en permanence si une tache leur est dévolue.

Je pense que je vais reprogrammer mon moteur avec cette méthode pour voir si ça fait une différence ou non...

Je fais un petit retour.

J'ai modifié le software pour que les threads des blocs ne tournent plus en permanence et qu'à chaque itération ils vérifient s'ils ont quelque chose à faire.
Maintenant c'est le scheduler qui les reveille.

J'ai pas encore testé sur plusieurs ordis, mais le taux d'occupation du CPU chute de 100% à 30-40% en fonctions des applications.

Donc a priori, c'est un schéma beaucoup plus efficace

Merci en tout cas