Journal problemes de threads

Posté par  .
Étiquettes : aucune
0
11
avr.
2004
Bonjour j'aurai besoin d'une ptite aide en java, jviens d'entamer la partie multiprocessus, et j'arrive pas a faire un truc tout con, a savoir lancer 3 threads comptant chacun respectivement jusqu'a 1 000 000 000, 500 000, et 1000...
A chaque fois tant que le 1er thread n'a pas fini les autres démarrent pas. J'ai essayé yield, notify, je sais pas trop par ou commencer, dans les tutorial du net ca parraissait simple mais bon visiblement pas assez pour moi... :-(

Le code est vraiment con donc jpense que l'erreur est plutot une erreur de compréhension de ma part plutot qu'une erreur de syntaxe.

Please, help me !!! :'(


dans mon main :
Proc test1= new Proc("test1");
Proc test2 = new Proc("test2");
Proc test3 = new Proc("test3");

test1.start(1000000000);
test2.start(500000);
test3.start(1000);

===============================

class Proc extends Thread
{
long i;
public Proc(String nom)
{
super(nom);
}

public void start(long nb)
{
run(nb);
}

public void run(long nb)
{
while (i<=nb)
{
i++;
// faut il mettre une instruction pour dire a un autre thread qu'il peut y aller a son tour ?
}
System.out.println("Le thread " + getName() + " a fini.");

}
}
  • # Re: problemes de threads

    Posté par  (site web personnel) . Évalué à 2.

    Ce n'est pas de cette façon qu'on démarre un thread : il faut redéfinir la méthode run() sans paramètre et appeler start() pour démarrer le thread :
    class MonThread extends Thread
    {
         private int nb;
         public MonThread(int nb) { this.nb = nb; }
         public void run()
         {
              int i;
              while (i <= nb) { /* ... */ }
         }
    }
    
    class Prog
    {
         public static void main(String args[])
         {
              (new MonthThread(1000000000)).start();
              (new MonthThread(500000)).start();
              (new MonthThread(1000)).start();
    
              /* ... */
         }
    }
    
    Note : pour que ça soit portable, il faut ajouter un appel à yield() dans la boucle des threads...
    • [^] # Re: problemes de threads

      Posté par  . Évalué à 1.

      AAAAHHHHHH c'est pour ca !!!


      1000 fois merci ! :-)

      C'etait effectivement tout bete, merci, merci, merci ! (ca fait 1003 merci)
      • [^] # Re: problemes de threads

        Posté par  . Évalué à 1.

        cela dit c'est souvent le bordel avec l'ordonnaceur des Threads java ... tu peux, en fonction de la VM, avoir ce genre de comportement sans que ton code soit source d'erreur ... sinon je ne vois pas raison d'être à yield ...
        • [^] # Re: problemes de threads

          Posté par  (site web personnel) . Évalué à 1.

          Il me semblait que c'était plutôt selon le système sur laquelle tournait la VM. Si les threads ne sont pas gérés par le système, alors ils sont exécutés de manière "séquentielle" (d'où l'intérêt de yield() pour la portabilité). A vérifier...
  • # Re: problemes de threads

    Posté par  (site web personnel) . Évalué à 2.

    En fait, je crois que le start qui existe déjà dans la classe Thread lance le run, mais ne fait pas que ça...
    Donc l'idéal, c'est de revoir ton code en ne réécrivant pas la fonction start...
    Mais plutôt en faisant un truc du genre:

    Proc test1= new Proc("test1");
    test1.setNb(10000000);
    test1.start();

    et ton run, tu ne lui passes pas de paramètre...

    La fonction setNb mettant à jour une donnée membre nb... Initialisée à 0
    dans le constructeur...


    Enfin, un autre truc... La variable i peut être déclarée dans la fonction run, non?


    Bon, je suis tombé dans un troll, ou c'était des questions sérieuses?
    • [^] # Re: problemes de threads

      Posté par  . Évalué à 0.

      Lol non c'etait bien des questions serieuses, mais ne tinquiete pas, tu as répondu admirablement bien, donc tout comme ton collegue un peu plus haut, pour toi aussi : merci :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.