(c++) boost::xtime offre une résolution de 1s.
(c) clock_t offre une résolution de 1ms.
Existe-t-il mieux ?

RDTSC (résolution = fréquence du cpu; faire attention aux cpus à fréquence variable---> 10 ticks à 2400MHz c'est pas pareil que 10 ticks 1800Mhz (sur le meme CPU))

et c'est le truc le plus imprécis qui existe.
 
une résolution de 1ms, c'est déjà du gros flou même sur un système temps réel mou.

Ca dépend de ce qu'il y à traiter, temps réèl ca veut pas dire rapide, ca veut dire "l'information sera récupérée et traitée dans le temps où elle est valide".
 
=> Un lecteur de vidéo à 24 images/s a des contraintes de temps réèl mou car si il saute une de ses échéances (à raison de 24 par seconde), c'est chiant (la vidéo saccade), mais ce n'est pas critique (on ne plante pas la totalité de la lecture de la vidéo / le système ne crashe pas)
 
Ca fait quand même un poil de plus 4ms. J'appelle pas ca un gros flou.
 
Sinon pour en revenir au sujet, le clock_t il a vraiment de manière effective la résolution à la ms ? Tout ce que j'avais pu trouver comme fonctions pour choper le temps (via Visual Studio 6), me donnait bien en théorie une résolution à la ms ou mieux, mais en pratique la valeur à 15ms du timer du PC...

Sous Windows, pour être un poil plus précis, il vallait mieux utiliser (depuis Win95) les MultiMedia Timer (qui sont basés sur la RealTimeClock du PIC si je ne dis pas de bétises):
http://msdn.microsoft.com/library/ [...] timers.asp
 
Mais j'ai cru comprendre qu'ils n'étaient pas assez précis et qu'il y avait des trucs mieux de nos jours. Je serais bien curieux de savoir...
 
edit: bah apparemment tout le monde utilise le RDTSC de nos jours via
QueryPerformanceFrequency et QueryPerformanceCounter.
 

C'est plutot le quantum de temps alloué à un thread avant d'être pré-empté. Windows n'est pas temps réel, si tu as une fiabilité de 10ms tu peux t'estimer heureux.