Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2818 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  Problème d'utilisation des Threads avec lib javacomm

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Problème d'utilisation des Threads avec lib javacomm

n°1746879
dukable
Posté le 16-06-2008 à 09:32:18  profilanswer
 

Bonjour,
 
alors voilà j'espère que quelqu'un pourra m'aider avec ça, je dois développer en ce moment un petit programme permettant d'établir la communication entre le PC et une machine reliée sur le port série.
 
Pour cela j'utilise la librairie javacomm de sun, et les thread, le problème étant que je dois récupérer des données sur l'appareil relié, donc il faut que pendant un certain temps, le PC envoit les chaines correspondant à l'initialisation, puise attende un certain temps, puis envois ses différentes requêtes, attende un certain temps, puis envois la chaine correspondant au retour en idle mode de l'appareil.
 
Le truc c'est que j'ai réussi à gérer la connexion, une requête, la déconnexion, mais à partir du moment ou j'execute plus de chose ça devient tendu, car je joue avec des sleeps pour faire ça, et si j'ai plus ou moins de requêtes, la durée des sleep doit être proportionnelle... bref avec les sleeps c'est pas jouable, que j'utilise la méthode événementielle de javacomm ou en utilisant les flux.
 
Apparement une technique serait de créer un nouveau thread à chaque fois... quelqu'un aurait déjà fait ça?
 
Sinon j'avais pensé mettre le premier thread en pause, par exemple celui qui envoit la requête, et le faire reprendre quand l'autre à finit le traitement, mais c'est Deprecated dans l'API Java.
 
J'espère être clair, et que quelqu'un ai déjà fait un truc du genre.
 
Merci :)

mood
Publicité
Posté le 16-06-2008 à 09:32:18  profilanswer
 

n°1747221
tempo14
Posté le 16-06-2008 à 21:06:48  profilanswer
 

effectivement le sleep est rarement la bonne solution.
Si je comprend bien tu es client: Tu envoie un message, et tu reçoit une réponse ?(c'est une question en fait)
 
Généralement dans les communication:  

  • soit on est séquenciel et un thread qui s'occupe de l'envoie et la reception est suffisant, en plus du thread principal,  
  • soit les messages peuvent être mélangé, et on a un thread pour l'emission, un pour la reception et le thread principal.


La communication entre threads se fait dans des queue fifo (Une queue par thread).  
 
Dans la queue, on peut mettre:

  • soit un objet compréhensible, voir une action,
  • soit le message, et laisser l'encodage décodage a une couche du thread principal


Voici un exemple de "queue" pour une communication entre thread (tu remarquera quelle est "thread safe" )
 

Code :
  1. public class FifoRxTx implements FifoRxTxInterface {
  2.     /** the len of the queue. 16 is an optimum value */
  3.     private int bufferLen = 16;
  4.     private byte[][] buffer;
  5.     private int readPtr;
  6.     private int writePtr;
  7.     //private Vector
  10.     /**
  11.      * Creates new Queue
  12.      */
  13.     public FifoRxTx() {
  14.         buffer = new byte[bufferLen][];
  15.         readPtr = 0;
  16.         writePtr = 0;
  17.     }
  19.     /**
  20.      * Creates new Queue
  21.      */
  22.     public FifoRxTx(int len) {
  23.         this.bufferLen = len + 1;
  24.         buffer = new byte[bufferLen][];
  25.         readPtr = 0;
  26.         writePtr = 0;
  27.     }
  30.     /**
  31.      * @return true if empty
  32.      */
  33.     public boolean empty() {
  34.         return (readPtr == writePtr);
  35.     }
  37.     /**
  38.      * @return true if full
  39.      */
  40.     private boolean full() {
  42.         // works only with buffer size = 16
  43.         //return (((writePtr + 1) & 15) == readPtr);
  44.         // otherwise use this (not optimized)
  45.         return (((writePtr + 1) % bufferLen) == readPtr);
  46.     }
  48.     /**
  49.      * Push an element to the queue. Note that it is a blocking call if
  50.      * the queue is full
  51.      *
  52.      * @param i
  53.      */
  54.     public synchronized void push(byte[] i) {
  55.         while (full()) {
  56.             try {
  57.                 wait();
  58.             } catch (InterruptedException e) {
  59.             }
  60.         }
  61.         if (i != null) {
  62.             buffer[writePtr] = i;
  63.             // works only with buffer size = 16
  64.             //writePtr = (writePtr + 1) & 15;
  65.             // otherwise use this (not optimized)
  66.             writePtr = (writePtr + 1) % bufferLen;
  67.         }
  68.         notifyAll();
  69.     }
  71.     /**
  72.      * return an element of the queue if present (non blocking call)
  73.      *
  74.      * @return an element or null
  75.      */
  76.     public synchronized byte[] peek() {
  77.         byte[] i = null;
  78.         if (!empty()) {
  79.             i = buffer[readPtr];
  80.             // works only with buffer size = 16
  81.             //readPtr = (readPtr + 1) & 15;
  82.             // otherwise use this (not optimized)
  83.              readPtr = (readPtr + 1) % bufferLen;
  84.             notifyAll();
  85.         }
  86.         return i;
  87.     }
  89.     /**
  90.      * Blocking call that return an element of the queue
  91.      *
  92.      * @return
  93.      */
  94.     public synchronized byte[] pop() {
  95.         while (empty()) {
  96.             try {
  97.                 wait();
  98.             } catch (InterruptedException e) {
  99.             }
  100.         }
  101.         byte[] i = buffer[readPtr];
  102.         // works only with buffer size = 16
  103.         //readPtr = (readPtr + 1) & 15;
  104.         // otherwise use this (not optimized)
  105.          readPtr = (readPtr + 1) % bufferLen;
  106.         notifyAll();
  107.         return i;
  108.     }
  111.     /**
  112.      * Wait for a message during a timeout
  113.      *
  114.      * @param timeOut time to wait
  115.      * @return the message or null
  116.      */
  117.     public synchronized byte[] pop(int timeOut) {
  118.         if (empty()) {
  119.             try {
  120.                 wait(timeOut);
  121.             } catch (InterruptedException e) {
  122.             }
  123.         }
  124.         return peek();
  125.     }
  127.     /**
  128.      * Flush the content (delete all data in it!)
  129.      */
  130.     public synchronized void flush() {
  131.         readPtr = 0;
  132.         writePtr = 0;
  133.         notifyAll();
  134.     }
  137. }


Message édité par tempo14 le 16-06-2008 à 21:10:40
n°1747365
dukable
Posté le 17-06-2008 à 09:35:15  profilanswer
 

Oui j'envois un message et je reçois une réponse. Le problème là, c'est que avec les sleeps c'est trop aléatoire, en plus selon le nombre de requêtes que j'ai a effectuer il faudrait que le sleep soit de longueur différente, donc c'est pas trop gérable proprement.
 
Avec les join() aussi ça ne marche pas.
 
En gros voici le topo:
 
1 Thread emetteur
1 Thread recepteur
Le programme principal.
 
L'idée ici c'est que l'emetteur, qui envoit les requêtes à l'appareil, va creer autant de thread qu'il y a de requêtes:
 
public void run() {
  Ecouteur thread2 = new Ecouteur(idIns, pouet(), idMethode, chemin_Portserie, pContext,connex);
   
                //Ce thread sert juste pour l'initialisation
                Initi thread3 = new Initi(retBuff(), idMethode, chemin_Portserie, pContext,connex);
 
  try {
                        //On lance l'init
                        thread3.start();
   communique("B" );
   sleep(3000);
   communique("B" );
                        //Et tant que l'init est pas finie on reste dedans grace au join()
   thread3.join();
   for (int i = 201 ; i <= 210 ; i++ ) {
           communique("A" + i );
           new Thread(thread2).start();
    thread2.join();
   }
   thread2.start();
   communique("A210" );
   thread2.join();
   communique("Z" );  
   close();
  } catch (InterruptedException e) {
 
  }
 }
 
Genre là dans la boucle, l'idée est de récuperer plusieurs fois AXXX, XXX correspond à un numéro, et l'appareil doit renvoyer des résultats. Le problème c'est que la machine est connectée en 1200 bauds et que il faut lui laisser le temps de répondre. Avec les join() même problème, des fois ça insère parfaitement les 10 résultats au final, mais en bidouillant avec des sleeps et autres... Impossible de faire ça proprement et de façon sûre (qui marche à chaque fois).


Message édité par dukable le 17-06-2008 à 09:38:33

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  Problème d'utilisation des Threads avec lib javacomm

 

Sujets relatifs
problème de conflit avec Include suivant langue, avec script pas à moiProblème création de menu avec Joomla ?
problème de gestion des getProblème infobulle JS sous IE
Petit problème de cadresProbleme reassemblage d'image
Probleme Izpack et fichier bash sous linuxProblème d'inscription
Problème de multiplication de doubles[Flash/actionscript]probleme clip qui reste
Plus de sujets relatifs à : Problème d'utilisation des Threads avec lib javacomm

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.060 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR