[JAVA] Probleme de surcharge CPU

Probleme de surcharge CPU [JAVA] - Programmation

Marsh Posté le 15-02-2002 à 12:26:33    

Bonjour
 
j'ai un probleme d'occupation cpu pour une application
réseau. cette derniere crée un thread qui boucle
à l'infini pour envoyer des messages qu'on lui donne...
le probleme est que cette boucle entraine une utilisation
maximale des ressources cpu, alors qu'on aimerait avoir un
comportement plus proche d'un daemon, ou encore d'un  
procédé de callback comme pour les i/o...
y-a-t-il une solution, spécifique java ou non ?

Reply

Marsh Posté le 15-02-2002 à 12:26:33   

Reply

Marsh Posté le 15-02-2002 à 12:51:00    

Un bout de code?????

Reply

Marsh Posté le 15-02-2002 à 12:58:06    

Dans ton Thread, il faut absolument qu'à un moment donné tu fasses :  
 
Thread monThread;
...
monThread.sleep(leTempsQueJeVeux);
 
où leTempsQueJeVeux est un entier en millisecondes (à vérifier pour l'unité).


---------------
Le site de ma maman
Reply

Marsh Posté le 15-02-2002 à 12:58:39    

voila en gros ce que fait le run() du thread:
 
while(m_stop == false)
{
 if (m_answer.isEmpty() == false)
 {
  synchronized(m_parentJob)
  {
   String ans = (String)m_answer.firstElement();
   System.out.println("Answer manager " + m_id + " > " + ans);
   outToClient.print(ans);
   m_answer.remove(ans);
  }
 }
}
 
m_answer est un vecteur, et outToClient... enfin c assez explicite  :wahoo:

Reply

Marsh Posté le 15-02-2002 à 14:37:05    

rajoute un Thread.yield() dans ta boucle : ca rend la main au système.
c'est indispensable.
 
Le thread.sleep() fonctionne aussi mais endoer ton thread pdt le temps que tu as définie, ce qui n'est pas forcément ce que tu souhaites.


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 14:46:32    

D'un autre côté, utiliser un Thread pour ça, ça me paraît douteux : utiliser un thread pour écouter une socket, d'accord, mais après...8|....je te suis pas! :D
 
Il sert à quoi, exactement, ton vecteur???

Reply

Marsh Posté le 15-02-2002 à 15:03:15    

Tu pourrais peut-etre aussi gagner en bufferisant l'affichage plutot qu'effectuer un "System.out.println"(je crois que cette fonction ne rend pas la main au thread principal tant qu'elle n'a pas finit)
Tu devrais gagner en fluidite.

Reply

Marsh Posté le 15-02-2002 à 15:07:31    

Voila une solution qui fonctionne très bien chez moi.
 
D'une part tu as ton thread qui contient un vecteur v
 

Code :
  1. public void run() {
  2.    while (not_finished) {
  3.         while (v.size() != 0) {
  4.            // faire qqch avec v[i]
  5.            // remove v[i]
  6.         }
  7.         try {
  8.            synchronised(this) {
  9.                  wait(2000);
  10.            }
  11.         }
  12.         catch (InterruptedException ie) {
  13.             // new message in the queue
  14.         }
  15.     }
  16. }


 
et d'autre part tu as une méthode pour ajouter des messages
 

Code :
  1. public synchronised void addMessage(Message msg) {
  2.       v.add(msg);
  3.       notify();
  4. }


 
and it works perfectly baby ;)
 
Dis moi si ca t'aide ...


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:10:37    

je persiste : si tu ne souhaite pas bloquer ton thread, fais un yield !
 

Citation :

public static void yield()
Causes the currently executing thread object to temporarily pause and allow other threads to execute.


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 15:12:51    

benou a écrit a écrit :

je persiste : si tu ne souhaite pas bloquer ton thread, fais un yield !
 

Citation :

public static void yield()
Causes the currently executing thread object to temporarily pause and allow other threads to execute.

 




 
tu risques d'avoir des probs de deadlock là. En fait tout dépend des requierments du systeme. Avec ma solution par exemple, il fait un test toutes les deux sec en inactivités ce qui n'est pas méchant.
 
Et il y a un notify qui enclence une InterruptedException dès que tu ajoutes un message donc c'est relativement correct.  
 
Maintenant faut pas utiliser ton thread pour autre chose que ca ;)


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:12:51   

Reply

Marsh Posté le 15-02-2002 à 15:13:33    

ok merci, je vais voir tout ca...
pour ce qui est du thread, c'est la seule solution que j'ai
trouvé, sachant que le thread parent gere la connection principale (d'ou le synchronized, histoire de ne pas send n'importe quand)... le pb c'est que je suis obligé de faire un appelle bloquant sur l'ecoute du client pour pouvoir detecter sa deconnection (et donc killer le process), mais en mm temps, il faut je puisse envoyer a cette mm connection des messages quand ils arrivent... voila le pourquoi du comment, j'espere que c'etait clair

Reply

Marsh Posté le 15-02-2002 à 15:15:12    

axel5 a écrit a écrit :

ok merci, je vais voir tout ca...
pour ce qui est du thread, c'est la seule solution que j'ai
trouvé, sachant que le thread parent gere la connection principale (d'ou le synchronized, histoire de ne pas send n'importe quand)... le pb c'est que je suis obligé de faire un appelle bloquant sur l'ecoute du client pour pouvoir detecter sa deconnection (et donc killer le process), mais en mm temps, il faut je puisse envoyer a cette mm connection des messages quand ils arrivent... voila le pourquoi du comment, j'espere que c'etait clair  




 
pas du tout. SI tu veux voir si la connec est bonne tu peux implémenter un protocole très simple, le ping pong. Ton servoir envoie un ping et si après un temps donné tu ne recois pas de pong tu considère que ton clien est down.


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:15:27    

darklord22 a écrit a écrit :

 
tu risques d'avoir des probs de deadlock là.



:??: pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec.
ou bien y a un truc qui m'échappe ...


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 15:17:27    

benou a écrit a écrit :

 
:??: pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec.
ou bien y a un truc qui m'échappe ...  




 
 
bin tu yeld donc il faut bien que on te réveille non? si le notify se crashe chze moi, le thread se réveillera de toutes façons au bout de 2 sec
 
si je faisais this.wait();
 
ce serait pareil que ta solution :D


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:21:38    

nan yield ca rend le main, mais ca arrête pas le thread ...
ca laisse juste les autres thread s'excuter.
ex :  
 
While (true) {
   Thread.yield();
}
 
ca ce ne sera pas bloquant : les autres thread fonctionneront encore !
D'ailleur, je pense qu'avant de se mettre en pause, le sleep() appelle le yield()


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 15:34:47    

Mais pourquoi tu veux pas écrire et écouter en même temps sur ta socket??? 8[  
Pasque sinon, le bout de mon client qui marche nickel (c'est un bout du client du nouveau chat Orange!! :D (à voir là : chat.orange.fr)
 
 
Le début :  
 
    public Client(String ip, int port) throws IOException {
        socket = new Socket(ip, port);
        reader = new BufferedReader(new InputStreamReader(server.getInputStream()));
        writer = new PrintWriter(new OutputStreamWriter(server.getOutputStream()), true);
        thread = new Thread(this);
        thread.setPriority(Thread.NORM_PRIORITY);
        thread.start();
    }
 
la méthode run()
 
    public void run() {
        String line;
        while (thread != null) {
            try {
                if ((line = reader.readLine()) != null) {
                   try {  
                      Message msg = MessageFactory.getMessage(line);
                      msg.anwser(parent);
                   } catch (MessageFormatException mfe) {
                   // gestion...
                   }
                } else {
                    fireEvent(NetworkEvent.SERVERDIED);
                }
            } catch (IOException ioe) {
                fireEvent(NetworkEvent.SERVERDIED);
            }
              thread.yield();
        }  
 
Et la méthode send :  
 
    public void send(String msg) {
        writer.println(msg);
        writer.flush();
    }
    }
 
 
 
Côté serveur, c'est un peu plus complexe :  
 
l'objet ServerSocket instancie un objet Runnable pour gérer la Thread, mais le run et le send sont similaires à ceux là....
 
Effectivement, y'a un yield, là dedans!! :D

Reply

Marsh Posté le 15-02-2002 à 15:39:10    

gfive a écrit a écrit :

Effectivement, y'a un yield, là dedans!! :D  




victoire !! :) :D :lol:


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 15:40:19    

damn!
 
benou  :gun:  :gun:  :gun:  
 
:D
 
bien vu  :fou:


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:40:37    

Ouais, mais ça fait un an que je l'ai codé, ce bout là!!

Reply

Marsh Posté le 15-02-2002 à 15:42:24    

darklord22 a écrit a écrit :

damn!benou  :gun:  :gun:  :gun:  




mdr ! :D


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 15:42:28    

t'as bossé pour orange?


---------------
What is popular is not always right, what is right is not always popular :D
Reply

Marsh Posté le 15-02-2002 à 15:44:08    

On a installé mardi, entre 2h et 7h!! :D
Et là, première rafale de corrections à faire!! :D
 
Mais je bosse pas chez Orange, je bosse dans une p'tite boite qui bosse pour orange.

Reply

Marsh Posté le 15-02-2002 à 15:45:14    

gfive > le pb c'est que le client envoye des messages (on attend avec un receive donc bloquant) et on lui renvoie un aquittement, et on rempile sur le receive.... a coté de ca, on peut avoir a tt moment a lui envoyer des messages... avec un seul thread, on serait obligé d'attendre de recevoir un msg pour pourvoir renvoyer le notre apres aquittement... d'ou un second thread avec section critique

Reply

Marsh Posté le 15-02-2002 à 15:50:00    

Ah ouais...J'ai fait autrement, pour l'acquitement, moi....: comme j'en attend pas toujours, j'ai un système d'objects qui attendent : quand j'envoie un message pour lequel je dois attendre une réponse, je met mon objet qui attend dans une HashMap, indexé par l'Id du message....Quand un acquitement est reçu, je lis l'ID, et si un objet attend cet Id là, j'appelle la méthode à appeller quand l'Id est reçu....

Reply

Marsh Posté le 15-02-2002 à 15:52:42    

oui... mais la voila, j'ai pas la main sur le protocole client, faut donc faire avek !  :crazy:

Reply

Marsh Posté le 15-02-2002 à 15:53:22    

shit!! :D

Reply

Marsh Posté le 15-02-2002 à 16:25:00    

darklord22 a écrit a écrit :

damn!
 
benou  :gun:  :gun:  :gun:  
 
:D
 
bien vu  :fou:  




 
:) :) :) Alors, qui c'est le plus fort ?
 
Solution : Facile, c'est Bill Gates. En anglais on dit qu'il a une "fucking policy". Une politique enculante, quoi !


---------------
Le site de ma maman
Reply

Marsh Posté le 15-02-2002 à 16:33:53    

Cherrytree a écrit a écrit :

 
:) :) :) Alors, qui c'est le plus fort ?




nananan ... ose pas me comparer à dark : il maîtrise bien plus de domaine que moi en Java !! :jap:


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 15-02-2002 à 16:35:13    

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!! :D

Reply

Marsh Posté le 15-02-2002 à 17:53:25    

gfive a écrit a écrit :

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!! :D  




Ah ! Qui sait, si ça se trouve il déteste programmer en Visual C++. Si ça se trouve, il déteste programmer :D


---------------
Le site de ma maman
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed