Lancer une interuption depuis un Thread

Bonjour à tous, :)

Je cherche une solution pour pouvoir lancer une sorte d'interruption depuis un thread. Je m'explique :

J'ai un objet que l'on appelra "MonObjet", qui lance un Thread "Rafraichisseur".
Le Rafraichisseur a pour but de scruter une source d'information externe de manière périodique.
En fonction des informations récoltées, le Rafraichisseur doit pouvoir déclancher une fonction de MonObjet pour traiter les nouvelles informations.

Pour faire bref, je cherche un system de signal, callback, ou interruption qui ne mette pas MonObjet dans un état d'attente et lui permette d'être prévenu immédiatement. :?

Merci d'avance !

Il faut savoir qu'un threads peut être interrompu !!
Que veut dire cettte notion ?

Un thread peut recevoir un évenement d'interruption, dés lors deux cas sont à envisager:
1. Le thread execute une méthode interruptible, auquel cas une exception InterruptedException sera levée afin de prevenir de l'arrivée de cet evenement
2. Le thread n'execute pas une méthode interruptible, un flag est stocké dans le contexte du thread, il faut dés lors penser a verifier l'état de ce flag Thread.interrupted()

Typiquement voici ce que pourrait être le corps de ton thread raffraichisseur

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public void run() { while( true ) { if( Thread.currentThread().interrupted() ) doJob(); try { Thread.sleep(5000); // méthode interruptible } catch(InterruptedException ie ) { doJob(); } } }

---

Pour ton MonObjet, il lui suffit d'avoir une reference de ton thread afin de pouvoir l'interrompre:

Code:

---

1 2	monRaffraichisseur.interrupt();

---

Si tu as des parametres à passer a ton threads regarde du coté de Exchanger du package concurrent.

Bref, tu as beaucoup d'outil à disposition mais c'est trés long détailler ici.

Citation:

---

Il faut savoir qu'un threads peut être interrompu !!

---

Arg !

Merci de ta réponse rapide. Malheureusement elle ne répond pas vraiment à ma question.

Je pensai a une interruption non pas comme un moyen d'arreter le thread, mais comme un moyen de communiquer de manière ponctuelle et non bloquante en demandant l'execution d'une méthode (comme une interruption unix, un callback C, un patern Listener Java, ect...).

De plus, je souhaiterai que le thread communique vers son père et non l'inverse.

Cette communication peut être effectuée avec un patern listener entre 2 objets, mais je doute que ca marche aussi bien entre un Thread et son père

l'interruption n'a pas forcement une sémantique d'arret mais peut au contraire avoir une sémantique de "démarage".

Si le thread a le design "j'attends jusqu'a ce qu'on m'interrompt pour lancer une méthode" alors l'interruption donne le feu vert !!

Sinon pour répondre à ta question,
MonObjet est un thread ou un simple objet ?
Si ce n'est qu'un objet, dans quel thread veut tu que sa méthode soit appelée ?

Pourquoi ton thread ne pourrait-il pas appeler la méthode de Mon Objet directement.
Sinon tu veux que le thred MonObjet puisse exécuter des requetes extérieurs, alors il faut qu'il passe son temps à regarder une file d'attente de commande à exécuter (automatique en .Net si MonObjet est un formulaire (JFrame)).
Tu ne peux pas interrompre un thread (celui de MonObjet) et lui dire de faire quelquechose (c'est vraiment risqué comme façon de coder, faut savoir où il a été arreté exactement etc.). ou alors tu vas monter dessus une couche de protection pour le multithread et dans ce cas là autant faire faire le travail à ton rafraichisseur.

Mais si tu pouvais donner plus de détails on pourrait t'aider beaucoup plus facilement.

Okay pour l'interuption, ca me servira très certainement un peu plus tard ;)

Pour en revenir a mon problème, MonObjet n'est pas un thread. Mon objet instancie le thread Rafraichissement. J'aimerai que Rafraichissement appel une fonction de l'instance de MonObjet qui l'a créé.

J'avais pensé à ça :

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

public class MonObjet {   public MonObjet() { ... }   public void ajouterRafraichisseur () { Rafraichisseur rafraichisseur = new Rafraichisseur(this); rafraichisseur.start(); }   public void traiterInfos(Infos infos) { ... }   }   public class Rafraichisseur extends Thread {   private MonObjet listener;   public Rafraichisseur (MonObjet listener) { this.listener = listener; }   private Infos checkSource() { // check la source }   public void run () { while(this.isAlive) { Infos nouvellesInfos; nouvellesInfos = this.checkSource(); if (nouvellesInfos != null) { this.listener.traiterInfos(nouvellesInfos); } Thread.sleep(100); } }   }

---

Mais étant encore débutant dans la programmation avec thread, conscient des problèmes qu'ils peuvent génères et un peu pésimiste, je me suis dit que ce ne serai surement pas la bonne méthode.

Mes recherches sur les thread ne m'ont pas permis de savoir si on pouvait faire l'appel de la méthode "traiterInfos" depuis le thread. J'imagine que même si c'était possible il y aurai également des problèmes de criticité sur cette méthode (synchronise s'applique-t-il a une méthode qui n'appartiend pas a un thread?)...
J'ai trouvé des exemples ou le thread et son père communiquent par Socket ou par Pipe, mais ca nessecite une boucle au niveau de MonObjet, ce qui ne m'arrange pas...

Citation:

---

Envoyé par FabienCx

Okay pour l'interuption, ca me servira très certainement un peu plus tard ;)

Pour en revenir a mon problème, MonObjet n'est pas un thread. Mon objet instancie le thread Rafraichissement. J'aimerai que Rafraichissement appel une fonction de l'instance de MonObjet qui l'a créé.

J'avais pensé à ça :

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

public class MonObjet {   public MonObjet() { ... }   public void ajouterRafraichisseur () { Rafraichisseur rafraichisseur = new Rafraichisseur(this); rafraichisseur.start(); }   public void traiterInfos(Infos infos) { ... }   }   public class Rafraichisseur extends Thread {   private MonObjet listener;   public Rafraichisseur (MonObjet listener) { this.listener = listener; }   private Infos checkSource() { // check la source }   public void run () { while(this.isAlive) { Infos nouvellesInfos; nouvellesInfos = this.checkSource(); if (nouvellesInfos != null) { this.listener.traiterInfos(nouvellesInfos); } Thread.sleep(100); } }   }

---

Mais étant encore débutant dans la programmation avec thread, conscient des problèmes qu'ils peuvent génères et un peu pésimiste, je me suis dit que ce ne serai surement pas la bonne méthode.

Mes recherches sur les thread ne m'ont pas permis de savoir si on pouvait faire l'appel de la méthode "traiterInfos" depuis le thread. J'imagine que même si c'était possible il y aurai également des problèmes de criticité sur cette méthode (synchronise s'applique-t-il a une méthode qui n'appartiend pas a un thread?)...
J'ai trouvé des exemples ou le thread et son père communiquent par Socket ou par Pipe, mais ca nessecite une boucle au niveau de MonObjet, ce qui ne m'arrange pas...

---

Tel que tu l'as fait cela n'est pas forcément mauvais. Actuellement tu as deux threads, le thread mère et le thread fils qui exécute ton rafraichisseur.
La c'est ton thread fils qui va appeler ta méthode de MonObjet. Donc c'est bien la méthode que tu veux, mais elle est exécutée par ton thread fils. Les problèmes que tu pourrais rencontrer sont ceux à l'intérieur de CheckSource et TraiterInfos. Là il ne faut pas que tu t'amuses à toucher aux même objets avec deux threads différents. Et le code que tu as collé ne permet pas de savoir. Donc avoir l'intérieur permettrait de mieux t'aider.

L'implémentation du schmilbick n'est pas encore faite donc j'aurai du mal à la poster... :?
Par contre, d'après ce que tu me dit, ce n'est pas spécialement moche d'appeler une méthode du père depuis le thread fils. Et ça m'arrange bien :)

Pour ce qui est des zones critiques, CheckSource n'aura pas de problème de criticité (c'est une demande d'information à un serveur multiclient). En revanche, traiterInfos est plus délicat (il met à jours des attributs de MonObjet).
Je viens de me documenter sur les verrous en java. L'idée qui me semble la meilleur est de gérer la criticité sur les attributs de MonObjet à l'aide d'un verrou pour chaque paire de getters/setters. Tout cela me semble assez sexy :D

Je met ma MV à feu et à sang et je vous dit demain si tout c'est bien passé.

Merci pour le coup de main !

Citation:

---

Envoyé par FabienCx

L'implémentation du schmilbick n'est pas encore faite donc j'aurai du mal à la poster... :?
Par contre, d'après ce que tu me dit, ce n'est pas spécialement moche d'appeler une méthode du père depuis le thread fils. Et ça m'arrange bien :)

Pour ce qui est des zones critiques, CheckSource n'aura pas de problème de criticité (c'est une demande d'information à un serveur multiclient). En revanche, traiterInfos est plus délicat (il met à jours des attributs de MonObjet).
Je viens de me documenter sur les verrous en java. L'idée qui me semble la meilleur est de gérer la criticité sur les attributs de MonObjet à l'aide d'un verrou pour chaque paire de getters/setters. Tout cela me semble assez sexy :D

Je met ma MV à feu et à sang et je vous dit demain si tout c'est bien passé.

Merci pour le coup de main !

---

Tu n'es pas obligé de mettre un verrou par paire de getters/setters. Surtout que tu seras embêté dès que tu voudras toucher à plusieurs getters/setters en << même >> temps.

Après sinon y a un truc qui pourrait peut-être te plaire : tu crées une condition (c'est quelque chose qui est associé à un verrou) qui signifie qu'il y a des infos à traiter, une queue contenant des infos à traiter et un thread qui s'occupe juste de traiter les infos.
Là dans traiterinfos tu fais une fonction qui ajoute l'info à la queue (proprement avec un verrou) et qui déclenche la condition.
Et là ton thread qui traite les infos se réveille prend l'info (toujours propremen) et la traite (toujours proprement) tandis que ton rafraichisseur retourne à son travail de rafraichissement.

Après tu choisi la méthode que tu veux en fonction de ton besoin. Mais la dernière aura l'avantage de te faire manier les conditions, qui sont fondamentales dans le multithreading.