Plusieurs tâches de mon application fonctionnent en arrière-plan. Ils se connectent à la base de données et exécutent des requêtes de sélection chronophages. Dans la plupart des cas, ces requêtes renvoient uniquement plusieurs enregistrements. De temps en temps, cependant, ils peuvent renvoyer des dizaines de milliers de disques. Tout cela est ensuite traité en boucle.Delphi - Réglage du temps de repos du fil
Étant donné qu'une telle situation peut se produire dans plusieurs threads en même temps, je ne souhaite pas que mon application utilise 100% du temps CPU lorsque ces threads traitent des données; Je ne veux pas non plus que tous les threads se battent pour le temps du processeur. Par conséquent, j'appelle la fonction Sleep() dans chaque itération des boucles dans ces threads.
Je ne sais pas, cependant, comment ajuster le temps de sommeil. Je ne veux pas que les boucles durent éternellement, donc la période de sommeil ne peut pas être trop longue. Je l'ai mis à 2 millisecondes dans chaque itération (dans chaque thread) (pourquoi 2ms? - c'est une bonne question :)). D'autre part, je pensais que je pouvais prolonger le temps de sommeil, mais appeler le sommeil seulement une fois toutes les itérations (disons Sommeil (100) toutes les 50 itérations). Quelle approche devrais-je choisir? Une insertion des boucles prend environ 30 ms chacune (sans sommeil).
Veuillez nous aviser.
Merci!
Mariusz.
Mais si cela fonctionne en arrière-plan sur un ordinateur qui a aussi quelqu'un qui travaille sur (par exemple, écrire une feuille de calcul), vous ne voulez que le processus d'arrière-plan rende le processus de premier plan inutilisable. – dummzeuch
Vrai, mais c'est pourquoi j'ai écrit que la priorité des threads d'arrière-plan peut être réduite, en gardant d'autres applications (ou le thread principal) sensibles tout en utilisant le potentiel du système complet. Sur les systèmes modernes (multi-core), le fait que tous les noyaux soient suffisamment chargés est beaucoup plus problématique que le manque de réactivité de l'application de premier plan. Et les E/S massives non optimisées représentent une menace beaucoup plus grande pour la facilité d'utilisation d'un système qu'une charge CPU élevée, de toute façon. – mghie