hello,
 
je suis intrigué:
 
1./
for(int i=0; i<5000; ++i)
{
   Sleep(1);
}
 
vs
2./
for(int i=0; i<50; ++i)
{
   Sleep(100);
}
 
pour 2./, je sors de la boucle eviron 5s apres y être entré-OK
pour 1./, la boucle dure plutot 30s que 5s...
 
Si qq1 a une explicatrion crédible, je suis preneur ))

SoWhatIn22 a écrit a écrit : hello,   je suis intrigué:   1./ for(int i=0; i<5000; ++i) {    Sleep(1); }   vs 2./ for(int i=0; i<50; ++i) {    Sleep(100); }   pour 2./, je sors de la boucle eviron 5s apres y être entré-OK pour 1./, la boucle dure plutot 30s que 5s...   Si qq1 a une explicatrion crédible, je suis preneur ))

 
Bof... ca fait quoi un petit facteur 1000...
c'est microsoft...

C'est peut-être approximatif le résultat de Sleep(durée).. C'est au moins ce qu'on attend, voire plus..
 
Cela serait interessant de savoir à partir de quelle valeur il y a "divergence". Jusqu'à 65 milliseconde, c'est-y bon ?
Vu qu'il y a un tick d'horloge tout les 65 ms, peut-être que le "raccordement" est vaseux (si je puis me permettre)...
 
Ou le compilateur qui fait des siennes en optimisant de travers.
 
C'est reproductible ? (Si une appli en tâche de fond monopolyse le temps CPU, il y a du retard).

Voir plus ? voire moins tu veux dire ?
sleep() l'argument est donne en secondes normalement...

>sleep() l'argument est donne en secondes normalement
 
euh, non. dans le MSDN:
-----------------
The Sleep function suspends the execution of the current thread for a specified interval.  
 
VOID Sleep(
  DWORD dwMilliseconds   // sleep time in milliseconds
);
-----------------
 
>C'est reproductible ?
sans pb. Je lance un thread qui ne fais que ca. Et il n'y a pas d'autre appli gourmande. Et la charge CPU est à zéro...

bon, a priori, ca doit être du au scheduling de NT. Sachant que le scheduler doit allouer a peu pres 20ms à chaque thread, celui-ci fait a peu pres 20 iterations. Mais quand le scheduler rend actif un autre thread, le Sleep(1) n'est pas executé.
donc voila.
Je vais donc faire autrement!
 
merci et a+

Sleep, pour ne pas encombrer le processeur inutilement dit au scheduleur qu'il peut passer à un autre et ne pas revenir sur le thread appelant avant que sleep est écoulé. Donc sleep a une précision qui dépend du nombre de threads de même priorité lancés.

Pardon j'ai confondu Sleep et sleep...