Discussion :

[Faiche]

Bonjour,

J'aurais besoin d'aide, non pas pour une question de code, mais plus une question de modélisation et algo :

Je fais un client pour une appli réseau, et je dois communiquer avec tous les autres clients que je rencontre.
Pour ça, je crée un thread par client rencontré, et je place tous ces threads dans un ThreadPoolExecutor, qui me gere les starts.

Jusqu ici, mes threads étaient standalone, c'est à dire qu'une fois qu'ils étaient instanciés et placé dans la méthode execute du threadpool, je ne m'en occupait plus, et ils se débrouillaient tout seuls.

Mon problème, c'est que maintenant j'aimerais pouvoir avoir la main dessus, pour pouvoir lancer a un instant T une action simultanée pour tous les clients avec lesquels j'ai réussi a rester connecté, dans la limite donnée a mon threadpool.

(note : je ne fais pas un machin de hack ou allez savoir quoi, donc pas besoin de dévier le sujet )

Plus concretement : j'ai 20 clients en mode run, avec qui le handshake s'est passé convenablement, et je voudrais lancer une requete a tous ces clients.

Donc j'aimerais avoir la main dessus, sauf que ce sont 20 clients parmis 4000, dont peut etre 100 qui ont été terminés, et le reste qui se trouve dans la blocking queue du threadpool.

Je ne sais pas du tout comment faire, étant donné que mes connaissances en Java ne se limitent qu'aux api de base.

Je pensais faire un tableau de weak references des instances de thread, ce qui fait que seules les 20 premieres references sont celles qui sont en mode run, mais au niveau du tableau, je ne sais pas du tout comment il réagit quand sa case vient de disparaitre, et puis je ne pense pas que ce soit tellement propre non plus.

Voila, j'espere que qqun aura une idée, et aussi que j'ai été assez explicite.

Je met tout de même mon bout de code, bien que je ne pense pas que ça apporte grand chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
// methode run()
    while (gRun)
    {
      PeerNode ptmp;
      byte[] btmp;
 
// autres initialisations
 
      for (int i = 0; i < mPeerIDList.size(); ++i)
      {
        btmp = mPeerIDList.get(i);
        if (!gContactedPeers.contains(btmp))
        {
          try
          {
// partie qui nous interresse -->
            ptmp = new PeerNode(btmp);
            gPeerThdPool.execute(ptmp);
            gContactedPeers.add(btmp);
// <--
          }
          catch (Exception ei)
          {
            Log.println("Peer ID corrupted or Peer unreachable : " + ei.getMessage());
            gCorruptedPeers.add(btmp);
          }
        }
      }
  }

[Faiche]

bon, j'ai trouvé des méthodes de hook (beforeexecute et afterexecute) mais il faut les redéfinir, et je suis pas tres sur de mon coup.

J'alloue le noeud, je le before execute pour dire que quand il s execute il se met dans un tableau, pour l after execute, je le retire du tableau, et ensuite je l execute.

Le probleme c'est que je dois donner ces infos pour chaque noeud, et j'en ai au minimum 3000.. bref, je suis pas hyper satisfait, mais c'est le seul truc un peu malin auquel j'ai pu penser pour le coup.

Qqun peut m'aider a approfondir le truc, ou me donner une autre direction s il y a mieux ?

[spekal]

J'ai l'impression que tu réfléchis trop en termes de threads.

Un objet, donc un client, existe indépendemment d'un thread. Je présume que tes threads sont de la forme "j'attends quelquechose et je réponds quelquechose". Même dans l'état "j'attends", chaque thread est dans un objet, objet qui existe, et que d'autres thread peuvent utiliser.

Quand un "truc" veut lancer une requête, le truc est dans un thread à lui. Ce thread peut interroger les clients, même s'ils ont été créés par d'autres threads. Le truc peut interroger les clients dans un thread à lui, même si ces client sont déjà pris en charge par un thread en attente.

Il existe quantités de possibilités, c'est à toi de construire ton approche.

[Faiche]

Ben mon probleme c'est que justement je n'ai pas la main sur ces objets.

Quand un thread se termine, le threadpoolexecutor doit s'en débarrasser, peut etre en mettant la reference pointant l'objet a null.
Probleme : si je garde un acces a cet objet par une reference classique, il ne sera pas libéré a la fin de son run, et je vais tres vite saturer ma mémoire.

Si je garde un acces en weak reference sur cet objet, ma reference pointera nulle part quand l'objet sera détruit, et si cette weak reference se trouve dans un tableau, je ne sais pas ce qui se passe : est ce que la case vaut null, ou la case est enlevée ?

Ensuite, imaginons je garde mes 3000 objets dans un tableau, pendant qu'ils se font executer a tour de role. Pour savoir quel objet est en run() je dois faire apel a isRunning(), SEULEMENT SI l'objet existe toujours.
Bref ça me fait environ 2N tests à chaque fois que je veux simplement connaitre mes 20 clients en run(), et c'est possible que pendant que je parcours le tableau, certains thread se soient lancés, d'autres se soient détruits, etc. Donc c'est un peu le bordel.

L'idéal pour moi serait d'avoir un tableau des threads en train de tourner sous la main, parce qu'ils sont en moyenne 20, et qu'il y a donc moins de chance qu'il se produise un changement pendant le parcours.

Une solution inélégante serait d'utiliser les hooks sus-cités, mais je ne suis pas sur et certain de leur comportement, et en plus ça me fait créer deux fonctions par thread mis dans le pool...

Une autre serait de refaire totalement un equivalent du threadpool, mais bon, si je peux faire autrement, c'est pas plus mal.

[spekal]

Je ne connais malheureusement pas assez bien les nouvelles librairies de threads pour te répondre.

En vieux java, il existe java.lang.ThreadGroup qui correspond très bien à ce que tu cherches (liste des threads actifs, etc). Il faut lancer les threads en précisant leur groupe ; je présume que cela doit pouvoir s'utiliser conjointement au paquetage concurrent, mais je ne sais pas comment.

Bon courage.