Bonjour,

J'utilise la methode Thread. sleep(double) pour limiter le nombre de calcul effectués par seconde...
Thread.sleep(1000/MyInteger);
MyInteger= Nombre de calculs par seconde.

Quand je lance ca sous eclipse le temps me semble respecté.

quand je compile mon jar, j'en fais un .exe et je lance le tout c'est 10 fois plus rapide.... il y a visiblement trop de calculs par seconde.... mes questions sont donc les suivantes...

- Thread.sleep(1000 ) met bien de Thread en pause pendant 1 seconde ?
- Cette valeur est elle exacte?
- Quelqu' un a t'il déja rencontré le probleme ?
- Y a t il une solution plus fiable ?

Merci

Je n'ai pas remarqué de problème avec l'utilisation de cette méthode, mais vérifie quand même que tu n'intercepte pas une exception InteruptedException que tu ne traîterais pas par exemple (cet exception peut se déclencher si d'autres threads demande au thread courant de reprendre par exemple).

Non, j'interceptes les erreurs et il n'y en a pas.

apparemment selon ce que j'ai lu dans les autres forums il y aurait 2 types de Threads, celui de la JVM et celui de l'OS... je pense que lors de l'execution sous Eclipse, j'utilise la gestion JVM et apres compilation c'est l'os qui s'en charge...

Je vais donc regarder à faire une sorte d'asservissement, je commence par placer mon double à 100 si je veux un delai de 100ms puis je regarde le délai réèl et corrige ma valeur... genre je m'appercois que le délai Réèl est de 80ms je passe ma valeur de sleep à 120 etc...

je pense utiliser la fonction "new georgian.calandar " pour recupérer le timestamp a mois que qq un ait mieux :)

Merci

Salut,

j'ai eu le meme constant sur un envoi de paquets rtp et le pire c'est que non seulement il y a une variante avec le java mais celon l'os le timestamp n'est pas le meme donc la solution que j'ai trouvé est de calculer ce timestamp

pour ce faire tu creer un thread qui va calculer ce timestamp en manipulant des opérations sur calendar qui est assez gourmand en terme de ressources.

long timestamp = -1

public void run() {
    Calendar cal = null;
    try {
         long duration = 10000;
         sleep(500);
        cal = Calendar.getInstance();
        long milli1 = cal.getTimeInMillis();
        sleep(duration);//petite pause pour avoir un meilleur visu du timestamp
        cal = Calendar.getInstance();
        long milli2 = cal.getTimeInMillis();
        timestamp = milli2 - milli1 - duration;//calcul du timestamp
    } catch (Exception e) { }
}

------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

WORA

Voila ce que j'ai fait... en gros une fois ma série de calcul terminée je regarde le temps écoulé... s'il est inférieure eu délai prévu entre chaque calcul, je fais des petites pauses d'un 1/10 du délai jusqu'a trouver un temps correct.
les temps m'ont l'air mieux sans pour autant etre certain de l'exactitude...

public void run(){ 
      long delai=10;
      while (true) {
            D0=new Date();
//--------------------------------------------
//ICI MES MOULTES CALCULS
//-------------------------------------------
            D1=new Date();
            while(D1.getTime()-D0.getTime()<delai){ 
                  try {
                        Thread.sleep(delai/10);
                  }catch(InterruptedException e){
                        System.err.println("erreur");
                  } 
                  D1=new Date();
            }   
      }
}

Salut,

tu auras toujours un décalage mais en calculant le timestamp ce décalage sera minisé exemple pour un cadencement précis de 20 j'atten 19.99



------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

WORA

Excuse moi, tu veux dire que mon getTime() ne me donne pas de "Vrai" Milisecondes ?
alors que le cal.getTimeInMillis(); est plus précis ?

nan,

je veux dire que lors de lexecution si tu veux exemple un sleep de pile poils 20 milli secondes celon le traitement à faire et malgré l'ajout d'un timestamp, tu auras toujours un legé décalage d'1 nano à 1 milli sec. c'est juste pour que tu ne panique pas lorsque tu t'en rendras compte :P


------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

WORA

Je dirais que dans tous les cas, les applis ne devraient pas être compilé en code natif, l'application perdant les avantages de l'environnement de la JVM ....

Les écarts de temps sont connus et resteront de cette façon ... c'est une approximation qui est faite par la JVM sachant que ce n'est pas un environnement de temps réel (bien que cela soit aujourd'hui possible ...) surtout sur un OS qui ne l'est pas. D'ailleurs l'OS y est pour quelques choses ;-)

Pour le calcul de temps, perso j'utilise la méthode nanoTime apparue avec Java 5 :
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime()
un t2-t1 suffit à avoir le timestamp ;-) sinon il reste la méthod currentTimeMillis() pour les versions antérieures

Concernant l'origine réelle du prob de l'appli compilé nativement, j'en sais rien du tout ;-)

++