Ma compréhension de la fonction de sommeil est qu'il suit "Au moins la sémantique" I.e. Sleep (5) garantira que le fil peut dormir pendant 5 secondes, mais il peut rester bloqué pendant plus de 5 secondes en fonction d'autres facteurs. Y a-t-il un moyen de dormir exactement une période de temps spécifiée (sans attendre occupé).
7 Réponses :
Non. Parce que vous êtes toujours en fonction du système d'exploitation pour gérer les fils réveil au bon moment.
Eh bien, vous essayez de vous attaquer à un problème difficile et d'atteindre
non.
La raison pour laquelle c'est "au moins une sémantique", c'est parce qu'après ces 5 secondes, un autre fil peut être occupé.
Chaque fil obtient une tranche de temps du système d'exploitation. Le système d'exploitation contrôle l'ordre dans lequel les threads sont exécutés.
Lorsque vous mettez un fil de dormir, le système d'exploitation met le fil dans une liste d'attente et lorsque la minuterie est sur le système d'exploitation "réveille" le fil.
Cela signifie que le thread est ajouté à la liste des threads actifs, mais il n'est pas garanti que t sera ajouté en premier lieu. (Et si 100 threads doivent être éveillés dans cette seconde spécifique? Qui ira en premier?)
Comme les répondeurs précédents ont dit: Il n'y a aucun moyen d'être exact (certains interruptions de système d'exploitation en temps réel suggéré ou de matériel et même ceux-ci ne sont pas exacts ). Je pense que ce que vous cherchez est quelque chose qui est juste plus précis que la fonction SLEEP () et vous constatez que cela dépend de votre système d'exploitation par ex. La fonction Windows Sleep () ou sous GNU la fonction nanosleep ().
http://msdn.microsoft.com /en-us/library/ms686298%28vs.85%29.aspx
http://www.delorie.com/gnu/docs/glibc /libc_445.html
Les deux vous donneront une précision à quelques millisecondes.
Il n'y a aucun moyen de dormir pendant une période de temps spécifiée à l'aide de Standard C. Vous aurez besoin, au minimum, une bibliothèque tierce qui offre une plus grande granularité, et vous aurez peut-être également besoin d'un noyau de système d'exploitation spécial tel que le temps réel Kernels Linux.
Par exemple, voici un Discussion de la fermeture de votre fermeture de systèmes Win32 .
Ce n'est pas une question C.
Comme d'autres l'ont dit, vous devez vraiment utiliser un système d'exploitation en temps réel pour essayer de y parvenir. Le synchronisation de logiciel précis est assez délicat.
Cependant ... bien que non parfait, Vous pouvez obtenir de meilleurs résultats meilleurs que «normaux» en stimulant simplement la priorité du processus qui nécessite de mieux calmer . Dans Windows, vous pouvez y parvenir avec le Ceci est également probablement possible sur d'autres plates-formes que de Windows, mais je n'ai jamais eu de raison de le faire, alors ne l'a pas testé. Edit: selon le commentaire de Andy T, si votre application est multi-threadé, vous devez également faire attention à la priorité attribuée aux threads. Pour Windows, il est documenté ici . < / p> Quelque fond ... A pendant le moment, j'ai utilisé Cependant, lorsque j'ai découvert le Aussi - essayez de minimiser les autres choses que le système d'exploitation fait pour aider à améliorer les chances de votre synchronisation fonctionnant mieux dans l'application où Cela compte. par exemple: pas de transcodage vidéo de fond ou de disque de déglingage ou quoi que ce soit alors que vous essayez d'obtenir du chronométrage de précision avec un autre code !! en résumé: Comme il peut être utile (bien que un peu de sujet), voici une petite classe que j'ai écrite il y a longtemps pour utiliser les comptoirs haute performance sur une machine Windows. Il peut être utile pour vos tests: chirestime.h SetPRiorityClass fonction. Si vous définissez la priorité au niveau le plus élevé ( realtime_priority_class: 0x00000100 ) Vous obtiendrez beaucoup meilleurs résultats de synchronisation. Encore une fois, cela ne sera pas parfait comme si vous demandez, cependant.
SETPRIORITYCLASS pour renforcer la priorité sur une application où je faisais une analyse en temps réel de Vidéo à haute vitesse et je ne pouvais pas manquer un cadre. Les cadres arrivaient sur le PC à un très régulier (entraîné par un cadre externe scragrabber HW) de 300 images par seconde (FPS), qui a déclenché une interruption HW sur chaque cadre que j'ai ensuite réparé. Étant donné que le timing était très important, j'ai collecté beaucoup de statistiques sur le chronométrage d'interruption (en utilisant QueryPerformEcanceCounter Stuff) Pour voir à quel point la situation était vraiment, et a été consterné aux distributions résultantes. Je n'ai pas les statistiques à portée de main, mais Fondamentalement, Windows entretient l'interruption chaque fois que cela se sentait comme celui-ci lorsqu'il est exécuté à la priorité normale. Les histogrammes étaient très désordonnés, le STDEV étant plus large que la période de mes ~ 3 ms. Fréquemment, j'aurais des lacunes gigantesques de 200 ms ou plus dans le service d'interruption (rappelez-vous que l'interruption est tirée à peu près toutes les 3 ms) !! IE: HW Interruptions sont loin d'être exactes! Vous êtes coincé avec ce que l'OS décide de faire pour vous. realtime_priority_class réglage et aspiré avec cette priorité, c'était significativement mieux et la distribution d'intervalles de service était extrêmement serrée. Je pourrais courir 10 minutes de 300 FPS et ne pas manquer une seule image. Les périodes d'entretien d'interruptions mesurées étaient à peu près exactement 1/300 s avec une distribution étroite.
Une histoire géniale et beaucoup de code fournis aussi :) Dommage que je n'ai que +1 à donner.
et si le programme est multithreadé, vous devez spécifier aussi une priorité élevée pour le fil de dormir.
Je devais juste essayer de faire 120Hz sur Windows et oui, ce n'est pas amusant du tout. J'ai essayé quelque chose de similaire à votre code et il convient de mentionner que l'exécution de ce code augmentera un noyau de votre CPU car elle ne dormira jamais. S'il est dormi, vous dormez sans moins d'~ 15.6ms.
tandis que Standard Linux n'est pas un système d'exploitation en temps réel, les développeurs de noyau accordent une attention particulière au long de la longue priorité du processus de priorité. Ainsi, un noyau de stock Linux est généralement suffisant pour de nombreuses applications douces en temps réel.
Vous pouvez planifier votre processus en tant que tâche en temps réel avec le Soyez prudent lorsque vous utilisez des tâches programmées en temps réel; Comme ils prennent toujours la priorité sur les tâches standard, vous pouvez facilement vous trouver de coder une boucle infinie qui ne renonce jamais à la CPU et bloque les administrateurs d'utiliser Il existe des variantes de Linux disponibles qui ont été travaillées pour fournir des garanties de temps réel. RTLinux a support commercial ; Xenomai et Sched_setschéduler (2) appel, à l'aide de planche_fifo ou planche_rr . Les deux ont de légères différences en sémantique, mais il peut suffire de savoir que une tâche planche_rr abandonnera éventuellement le processeur à une autre tâche de la même priorité due aux tranches de temps, tandis qu'un Sched_Fifo < / Code> La tâche ne fera que renoncer à la CPU à une autre tâche de la même priorité due à bloquer les E / S ou un appel explicite à Sched_yieli (2) . .
SSH pour tuer le processus. Donc, il pourrait ne pas nuire à exécuter un sshd à une priorité plus élevée en temps réel, au moins jusqu'à ce que vous soyez sûr que vous avez résolu les pires bugs.
en.wikipedia.org/wiki/real-time_operating_system
"Sans attendre occupé" <- Vous ne pouvez même pas le faire avec une attente occupée. Votre fil peut être interrompu en attendant. (Peut-être que certaines priorités de Windows en temps réel pourraient être utiles)
Définir "exact". Même avec un assembleur codé à la main attaché à une interruption matérielle, vous allez avoir des effets dus aux caches manquées et même d'attendre que le pipeline d'instruction soit effacé et remplissez. Même avec une boucle occupée, vous allez être désactivé par microsecondes. Qu'est-ce que "exact"?