récupération d'une référence de Thread

Version imprimable

21/02/2008, 09h24
tiamat

récupération d'une référence de Thread

Bonjour à tous,

j'ai un probleme de conception, avant de me lancer dans le codage je veux être sur de faire le bon choix d'archi pour mon appli...

Je vais tenter d'être clair.

J'ai un Thread A qui fait un pooling d'une connexion sur port USB et qui attend des commandes à envoyer.

Par contre ce Thread A est créé au démarrage de mon appli et cette même appli démarre une Servlet B qui écoute des commandes distantes.

Donc mon problème est que ma Servlet B en recevant un message doit envoyer ce message à mon Thread A mais n'a pas de référence sur ce Thread...
Donc pour ma Servlet B (ou même un autre Thread), comment récupérer la référence sur ce Thread A sans avoir le contexte principal ?

J'avais pensé stocker la référence du Thread (Thread.getId()) dans un fichier et le récupérer depuis ma Servlet B en créant un objet du même type et lui renseigner la bonne référence de l'objet, mais je ne suis pas sur que l'on puisse faire ça.

Pourriez vous m'éclairer sur les pratiques de récupération de référence de Thread ? je suis sur que ce problème est fréquent et j'ai toujours réussi à pallier à ce probleme via des comm par fichier mais je me rend compte que ce n'est pas forcément très fiable...

Merci de votre aide.
Tiamat.
21/02/2008, 11h53
LoveOracle

Je ne comprends pas bien ton besoin... tu veux faire communiquer 2 processus entre eux ? Pourquoi ne pas utiliser RMI ?
21/02/2008, 14h33
Alkhan

bonjour,

Si c'est ton appli qui lance ta thread A et ta servlet B alors pourquoi ne pas passer la référence de A lors de l'instanciation de B ?

Le design pattern singleton !
Ton Thread est créé dans une classe Pool. Tu fais ainsi :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Pool
{
  private static Pool instance;
 
  private Pool()
  {
    ...
  }
 
  private Pool( blabla )
  {
    ...
  }
 
  public static Pool getInstance()
  {
    if( instance == null ) { instance = new Pool(); }
    return instance;
  }
}

Et dans ta Servlet :

Code:

Pool monPool = Pool.getInstance();

21/02/2008, 20h58
tiamat
Salut Dinobogan,

Merci pour ta réponse.
donc mettons le cas dans mon main, je crée une class MonThread qui va créer un Thread, et en ajoutant une méthode:
Code:

1 2 3 4 5 6 public static MonThread getInstance() { if( instance == null ) { instance = new Pool(); } return instance; }
De ce fait dans ma Servlet B, je peux faire:
Code:

1 2 MonThread thread = MonThread.getInstance();
et je récupèrerais l'instance du thread MonThread présent dans la JVM ?
c'est bien ça ?

désolé mais je ne connais pas trop les design pattern singleton...
Merci,

Tiamat.
22/02/2008, 10h36
dinobogan
Oui, c'est exactement ça.

Si tu veux empêcher les objets de conserver une instance de "MonThread", tu peux aussi passer uniquement par des méthodes static pour commander le thread, à toi de voir. Du coup, la méthode "getInstance" devient private et toutes les méthodes d'accès deviennent static :
Code:

1 2 3 4 5 6 7 public static void envoiMessage( String s ) { MonThread thread = getInstance(); thread.traiteMessage( s ); } ...
A toi de voir selon tes besoins ;)
24/02/2008, 00h50
tiamat

Merci beaucoup pour ta réponse !

par contre j'ai une question qui me vient du coup... dans le cas ou j'ai plusieurs instances de MonThread (ce qui n'est pas le cas...), de ce fait la méthode getInstance() n'a pas la possibilité de venir récupérer le bon objet par cette méthode ?

Je vais faire un essai comme ça et je reviens vers vous.
Merci,

Tiamat.
25/02/2008, 09h50
dinobogan

Citation:

Envoyé par tiamat

Merci beaucoup pour ta réponse !

par contre j'ai une question qui me vient du coup... dans le cas ou j'ai plusieurs instances de MonThread (ce qui n'est pas le cas...), de ce fait la méthode getInstance() n'a pas la possibilité de venir récupérer le bon objet par cette méthode ?

Je vais faire un essai comme ça et je reviens vers vous.
Merci,

Tiamat.

Jamais tu ne pourras avoir plus d'une instance de MonThread. La méthode "getInstance" te renverra toujours la même instance, quand bien même tu l'appellerais mille fois. De plus, tous les constructeurs sont private, donc il n'y a aucun autre moyen d'obtenir une instance que de passer par "getInstance".

Il me semble qu'il s'agit plus d'un problème de synchronisation.

Le Thread A devrait mettre à disposition un objet de synchronisationsur lequel il serait en atttente (wait)

Les threads (de tes servlet) pourrait alors lancer un notifyAll() aprés avoir inscrit le message dans la liste des messages à traiter.

Typiquement

ThreadA

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
       while( !demandeArret) {
                Message message = null;
                synchronized(demandes) {
                       while( demandes.isEmpty() ) {
                            try {
                                demandes.wait();
                            }
                            catch(InterruptedException ie ) {
                                 /* do nothing */
                            }
                        }
                        message = demandes.pop(); // prends un message en le retirant de la liste des messages à traiter
                 }
                 if( message != null ) {
                       // traiter le message
                       // le traitement de ce message ne bloque pas "demandes"
                       // ce qui permet aux autres threads de continuer a inscrire
                       // demandes
                 }
             }

ThreadB
/** Ce code devrait être directement écrit dans l'objet "demandes"
mais comme je ne voulais pas l'écrire ici :P
*/

Code:

1
2
3
4
5
6
  private void sendMessage( Message mess ) {
                   synchronized( demandes ) { 
                        demandes.add( mess );
                        demandes.notifyAll(); // reveil le ThreadA si besoin
                   }
             }

De cette façon, ton ThreadA ne se reveillera QUE lorsque des demandes sont à traiter et tu n'as pas besoin de connaitre le ThreadA.
Par contre la problèmatique se déplace puisque tes autres threads auront besoin de connaitre l'instance de l'objet permettant d'inscrire des demandes.

Ce code n'est qu'un exemple, je ne sais pas ce que sont tes messages, et je n'ai pas écrit l'objet "demandes" qui n'est même pas typé dans l'exemple.
J'ai écrit ce code directement sur ce formulaire donc des erreurs de typos peuvent s'être glissées.

25/02/2008, 13h09
tiamat

bon j'ai testé avec la méthode getInstance dans mon ThreadA, qui est appellée par ma Servlet B, par contre je vérifie l'ID du Thread et je m'aperçois que les ID ne correspondent pas...
le Thread A est créé avec un Thread.id de 64, et lorsque je fais un getInstance dans ma servlet, l'instance.id du ThreadA récupéré est 65...

donc après je ne sais pas si il n'y a toujours qu'une seule instance du Thread A en mémoire ou si il en a créé deux...
25/02/2008, 14h44
dinobogan

Comment la classe MonThread fabrique une nouvelle instance de Thread ?
Si tu as moyen de poster le bout de code utilisé, ce sera plus facile.
Un id de Thread identifie un thread. Deux numéros différents décrivent deux threads différents. Tu as coder le singleton de manière un peu bancale ;)

voici le bout de code:

ThreadUSB:
j'initie l'instance dans mon Thread

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
private static USBThread instance;
...
	public static USBThread getInstance()
	  {
	    if( instance == null ) { instance = new USBThread(); }
	    return instance;
	  }
 
	public void run(){
		instance = this;
		cmd = null;
		log.debug("Démarrage Thread USB "+Thread.currentThread().getId());
		com = new ComUSB();
		com.start();
 
		while(fin != 1){
			synchronized(this){
			try{
				this.wait();
				log.debug("Traitement du message");
				process();				
				cmd = null;				
			}catch(Exception e){
 
			}
			}
 
		}
 
	}

et dans mon autre bout de code je fais:

Code:

1
2
3
4
5
6
 
		USBThread usb = USBThread.getInstance();
		synchronized(usb){
		usb.sendCommand(cmd);
		usb.notify();
		}

en faisant cela, l'instance récupérée par getInstance est différente de celle créée au début.

Merci de ton aide.
Tiamat.

25/02/2008, 16h41
tiamat

à moins que le fait que je mette mon Thread en mode wait() empêche de récupérer sa référence ? (une question en passant...)
25/02/2008, 16h47
dinobogan

As-tu fais une erreur de frappe lorsque tu dis que ThreadUSB contient "getInstance" qui renvoie une instance de USBThread ?
25/02/2008, 16h48
dinobogan

Citation:

Envoyé par tiamat

à moins que le fait que je mette mon Thread en mode wait() empêche de récupérer sa référence ? (une question en passant...)

Non, car la référence est obtenue via un autre thread. C'est le code dans la méthode "run" qui est mis en parallèle.
25/02/2008, 16h52
tiamat
non non c'est bien ce que j'ai codé.

j'ai une classe ThreadUSB qui a les méthodes suivantes:

sendCommand()
fin()
run()
process()
public static USBThread getInstance()

par contre je crée l'objet instance comme ceci:
Code:

1 2 private static USBThread instance;
et je charge l'instance dans la méthode run() par:
Code:

1 2 instance = this;
au démarrage du Thread pour être sur qu'il sera la seule référence par la suite.

pourquoi ? ai je fait une erreur ?

J'ai pas lu en détail la discution, mais déjà une chose, la méthode de singleton est fausse.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 public class Pool { private static Pool instance; private Pool(){} public static Pool getInstance() { if( instance == null ) { instance = new Pool(); } return instance; } }
le bloc getInstance n'est pas synchronisé et donc, il peut y avoir x objects au lieu d'un seul.

Si un premier appel a passé le test "if (instance == null)", avant que l'instance de Pool soit créée et affecté à la variable "instance", il peut y avoir un deuxième appel qui va lui aussi passer au travers du test et donc provoquer une nouvelle instanciation de Pool.

Il faut utilser :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 public class Pool { private static Pool instance; private Pool(){} public synchronized static Pool getInstance() { if( instance == null ) { instance = new Pool(); } return instance; } }
Personnellement, je préfère ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 public class Pool { private static Pool instance = new Pool(); private Pool(){ } public static Pool getInstance() { return instance; } }
[EDIT]
Je viens de lire un peu plus ton problème.
Si je comprend bien, tu as une servlet qui récupère des commandes à renvoyer sur le port USB?

Si c'est bien ca , regarde du coté de la classe ConcurrentLinkedQueue qui te permet de mettre en place une architecture producteur/consommateur qui devrait te rendre service.

edit2 :
http://louis.cova.neuf.fr/blocs-notes/page14.html
http://www.javalobby.org/java/forums/m91820807.html

++

25/02/2008, 17h36
dinobogan

Bien vu pour le synchronized :oops:
J'ai écrit en vite flash, mais ce n'est pas une excuse ;)

Sinon, qui fait l'appel à "start" pour démarrer le thread ?
Ce n'est pas un singleton que tu as créé.

Et du coup je ne comprends plus : si tu fais "instance=this", tu es dans la classe USBThread. Or tu me dis que la méthode "run" est dans ThreadUSB 8O
Y-aurait-il une relation d'héritage entre ThreadUSB et USBThread ?
Tu devrais utiliser le singleton comme il faut, en cachant la classe USBThread à l'utilisateur.
25/02/2008, 18h08
tiamat

Salut Spoutnik,

merci de ton post, j'avais effectivement lu sur un article qu'il y avait un risque d'accès conccurent si on ne synchronizait pas le getInstance, ce que j'ai fait, donc pas de soucis la dessus.

après quelques tests, il semblerait que cela tourne correctement, mais un truc qui m'échappe c'est qu'en récupérant le Thread.getId() de chaque coté (Thread A d'un coté, et dans ma Servlet), je me rend compte que l'ID n'est pas le même...

par contre ils ont l'air de bosser avec le meme objet...

je vais regarder la classe ConcurrentLinkedQueue, meme si j'ai déjà établi mon protocole (basé sur XML), mais ça vaut quand meme la peine de jeter un coup d'oeil.
25/02/2008, 18h17
tiamat
oui pardon y a que USBThread...ThreadUsb je l'ai écrit un peu vite...

voici le déroulement.
un thread main crée le USBThread:
Code:

1 2 USBThread usb = new USBThread(); usb.start();
la méthode run() de mon USBThread initie l'instance:
Code:

1 2 public void run(){ instance = this;....
la classe USBThread contient aussi un getInstance():
Code:

1 2 3 4 5 public synchronized static USBThread getInstance() { if( instance == null ) { instance = new USBThread(); } return instance; }
et ma servlet qui a besoin de récupérer la référence de USBThread fait ceci:
Code:

1 2 3 4 5 USBThread usb = USBThread.getInstance(); synchronized(usb){ usb.sendCommand(cmd); usb.notify(); }
j'espère que c'est un peu plus clair...
A+

instance = this dans le run ... bof bof... :?;)

un petit exemple avec les queues bloquantes :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
 
public class USBThread {
	//private static Logger log = Logger.getLogger(USBThread.class);
 
	private final BlockingQueue <String> queue = new LinkedBlockingQueue<String>();
 
	private static USBThread instance  = new USBThread();
	private ComUSB usbCommunicator  = new ComUSB();
   // private ComUSB com = new ComUSB();
 
	private USBThread(){
		//log.debug("Construnction Thread USB singleton"+Thread.currentThread().getId());
		System.out.println("Construnction Thread USB singleton ThreadID : "+Thread.currentThread().getId());
		usbCommunicator.start();
	}
 
    public static USBThread getInstance(){
    	//log.debug("Get Thread USB singleton"+Thread.currentThread().getId());
    	System.out.println("Get Thread USB singleton ThreadID : "+Thread.currentThread().getId());
    	return instance;
    }
 
    public void addMessageInQueue(String message){
    	//log.debug("addMessageInQueue : "+message);
    	System.out.println("addMessageInQueue : "+message);
    	queue.add(message);
    }
 
 
    class ComUSB extends Thread {
 
    	public void run() {
    		//log.debug("starting usbCommunicator Thread ");
    		System.out.println("starting usbCommunicator (customer) Thread ThreadID : "+Thread.currentThread().getId());
	        try {
				while(true) {
					String message =  queue.take(); // enleve le premier element de la pile;
					sendUSBMessage(message);
 
				}
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				System.out.println(e);
			}
    	}
 
    	private void sendUSBMessage(String message) {
    		//log.debug("processing message from Queue : "+message);
    		System.out.println("processing message from Queue : "+message);
    	}
    }
 
 
    public static void main(String args[]){
    	new MessageGenerator().start();
    	new MessageGenerator().start();
    	new MessageGenerator().start();
    	new MessageGenerator().start();
    }
 
}
 
class MessageGenerator extends Thread {
	int cpt = 0;
	int nbIterations = 10;
	public void run() {
		while(true && cpt<nbIterations) {
			USBThread.getInstance().addMessageInQueue("test N° :" +cpt+" GeneratorID : "+Thread.currentThread().getId());
			cpt++;
		}
	}
}

tu as un singleton (USBThread) accessible par getInstance.
Ce singleton gère un consommateur de message 'ComUSB' qui ici affiche le message traité, à toi de l'adapter pour un envoi vers l'usb.

Le consommateur reste en attente d'un message non traité (il se bloque), dès qu'il y en a un, il le traite.

'MessageGenerator' simule un producteur de messages. Dans ton cas, ce sera ta servlet qui ajoutera des messages dans la pile via la méthode statique sur l'instance unique 'USBThread.getInstance()'
Ici, j'en ai mis 4 et 10 messages par générateur.

Si le "consommateur" ne va pas assez vite par rapport au producteur, les messages sont empilés et traités dès que possible, dans l'ordre premier arrivé, premier traité (FIFO).

J'espère que ca t'aidera

++

26/02/2008, 08h53
tiamat

ah oui effectivement c'est quand même plus propre et beaucoup mieux géré avec les queues bloquantes... je vais m'y pencher.

Merci Spoutnik et Dinobogan, je passe en résolu la discussion,même si il me reste quelques doutes sur l'unicité du USBThread, mais je m'y colle en le faisant évoluer avec le ConccurentQueue.

Tiamat. :lol:
26/02/2008, 10h19
Spoutnik

Citation:

même si il me reste quelques doutes sur l'unicité du USBThread, mais je m'y colle en le faisant évoluer avec le ConccurentQueue.

histoire de t'enlever tout doute :
http://christophej.developpez.com/tu...n/multithread/
et en particulier :
http://christophej.developpez.com/tu...ultithread/#L4
(ici, je t'ai mis un initialiseur static)

Bonne lecture

++
29/02/2008, 11h35
tiamat

Je te remercie Spoutnik,

j'ai bien pris en compte ton tuto, bien clair et très enrichissant !
donc après quelques essais, tout marche bien et je n'ai bel et bien qu'une seul instance de mon Thread en mémoire.
Je n'ai pour le moment pas rencontré de problèmes d'accès conccurentiel, mais au vu de mon archi, cela risque d'être très peu fréquent.

Merci,
Tiamat.