Discussion :

[ToTo13]

Bonjour,

suite à quelques soucis avec ma propre classe de gestion des threads, j'ai décidé d'utiliser un ThreadPoolExecutor avec une SynchronousQueue.

Voilà exactement ce que je veux faire :
- je veux disposer de N threads, ni plus ni moins.
- je ne veux surtout pas que ces threads soient détruits après utilisation car ils vont être réutilisés de nombreuses fois.
- je veux pouvoir passer des paramètres pour les calculs.

Voici ma classe qui étend la classe Thread qui effectue les calculs :

Code java :

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
 
private class MaClasseThread extends Thread
{
 
private int number = -1 ;
 
public MaClasseThread(int number)
	{
	super() ;
	this.number = number ; // Numéro unique (bien évidemment).
	}
 
public void Parameters(Object... parameters)
	{
	// ... on récupère les paramètres
	}
 
public void run()
	{
	// ... on fait la travail ici en fonction des paramètres
	}
}

Je construits ma synchronous queue et mon ThreadPoolExecutor :

Code java :

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

1
2
3
4
5
6
 
	BlockingQueue<Runnable> queue = new SynchronousQueue<Runnable>() ;
	for (int i=0 ; i < N ; i++)
		queue.add(new MaClasseThread(i)) ;
 
	ThreadPoolExecutor tpe = new ThreadPoolExecutor(N, N, ?, TimeUnit.MILLISECONDS, queue) ;

J'ai mis un '?' car je ne sais pas quoi mettre car je veux les garder vivant indéfiniment.

Questions :
- comment récupérer le premier thread libre ?
- comment lui passer le travail que je souhaite ?
- comment le lancer après passage des paramètre de calcul ?


Merci par avance

[professeur shadoko]

pas la peine de se pose la question du premier Thread libre.
pour les tâches voir la doc de ExecutorService

[thelvin]

Je sais pas trop pourquoi tu t'amuses à créer tes threads, et qu'est-ce que tu essaies de faire en les mettant dans la queue.
Les threads, c'est le boulot du ThreadPoolExecutor. Oublie-les.

BJ'ai mis un '?' car je ne sais pas quoi mettre car je veux les garder vivant indéfiniment.

Ce que tu veux. Ce sera ignoré, puisque le max et le core sont égaux, donc il n'y aura jamais plus de threads que le core, et donc jamais aucun candidat à l'arrêt.

[ToTo13]

pas la peine de se pose la question du premier Thread libre.
pour les tâches voir la doc de ExecutorService

Ben... comment est ce que je le récupère ?

Je sais pas trop pourquoi tu t'amuses à créer tes threads, et qu'est-ce que tu essaies de faire en les mettant dans la queue.
Les threads, c'est le boulot du ThreadPoolExecutor. Oublie-les.

Ok.
Donc je les passe directement au ThreadPoolExecutor. Mais avec quelle méthode ? submit, newTaskFor ?

Ce que tu veux. Ce sera ignoré, puisque le max et le core sont égaux, donc il n'y aura jamais plus de threads que le core, et donc jamais aucun candidat à l'arrêt.

Ok merci.

[thelvin]

Donc je les passe directement au ThreadPoolExecutor. Mais avec quelle méthode ? submit, newTaskFor ?

Tu sais, newTaskFor() est protected. Ce n'est pas franchement ce qu'on attendrait d'un moyen de soumettre une tâche à l'ExecutorService.
D'ailleurs, la JavaDoc indique à quoi ça sert : en gros encapsuler un Runnable ou un Callable dans un objet tâche gérable par l'ExecutorService.

submit(), donc.

[ToTo13]

Tu sais, newTaskFor() est protected. Ce n'est pas franchement ce qu'on attendrait d'un moyen de soumettre une tâche à l'ExecutorService.
D'ailleurs, la JavaDoc indique à quoi ça sert : en gros encapsuler un Runnable ou un Callable dans un objet tâche gérable par l'ExecutorService.

submit(), donc.

Effectivement, je n'avais pas vu le protected. Merci.

Je soumets donc mes classes runnable grâce à cette méthode.
Je vois donc comment lancer des tâches via le ThreadPoolExecutor comme cela est fait ici.
Mais à chaque itération, on crée un nouveau thread que l'on donne au ThreadPoolExecutor. Or ce que je voudrai c'est éviter de ré-allouer à chaque itération, donc j'ai besoin de pouvoir passer les paramètres à mon thread avant de le donner au ThreadPoolExecutor.

[professeur shadoko]

à chaque boucle tu crée un Callable qui est pris en charge par un Thread qui se libère dans le pool. tu ne crée pas un nouveau Thread (le nombre de Thread dépend de la stratégie de l'executor que tu as choisi)

[ToTo13]

Ok.
Mais je ne vois définitivement pas comment utiliser un ThreadPoolExecutor pour résoudre mon problème :-(

[thelvin]

Mais je ne vois définitivement pas comment utiliser un ThreadPoolExecutor pour résoudre mon problème :-(

Le problème que tu essayais de résoudre, et qui est résolu par ThreadPoolExecutor, c'est :

tu avais des tâches à faire faire, par un nombre de threads limité et fixe, et tu ne savais pas comment gérer tes threads pour attendre qu'il y en ait un de libre pour exécuter une tâche, et quand il a fini prévenir qu'il est libre, etc.

Avec un ThreadPoolExecutor :
- Tu le configures en disant combien de threads min, combien de threads max (en l'occurrence la même chose pour les deux,) et quelle queue utiliser pour stocker les tâches en attente.
- Tu lui envoies des tâches, il les exécutera quand il pourra.
- Les threads, c'est son problème, pas le tien.

ThreadPoolExecutor résout le problème que tu avais. Le reste ne change pas d'un iota.

[ToTo13]

Chaque fois que je regarde un exemple d'utilisation d'un ThreadPoolExecutor, je vois que l'on lance les calculs avec quelque chose qui est toujours du style :

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
 
ExecutorService executor = new ThreadPoolExecutor(5, 5, 50000L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<Runnable>(400)) ;
...
/* Une boucle ou autre pour lister les calculs.*/
	{
	Parameters parameters = ... ; // Bref un truc qui gère les paramètres.
	executor.execute(new Runnable()
		{
		public void run()
			{
			process(parameters) ;
			}
		}
		) ;
        }

Donc pour chaque nouvelle configuration de calculs, on doit instancier une nouvelle classe de type Runnable qui tient compte des paramètres.
- 1 - je souhaiterai éviter cette nouvelle instanciation systématique.
- 2 - les paramètres sont gérés en dehors de la classe, or dans mon cas il y a calcul d'un fichier de paramètres qui est très lourd et que je voudrai rentrer dans le Runnable (ça à la rigueur je sais comment faire, mais je trouve ça moche et risqué).

[thelvin]

- 1 - je souhaiterai éviter cette nouvelle instanciation systématique.

Pourquoi faire ? C'est juste un objet. Ce n'est rien comparé au reste de la mécanique de soumission des tâches.

Si vraiment tu veux éviter ça, effectivement tu vas devoir te passer de ThreadPoolExecutor, et le recoder toi-même, avec un mécanisme pour passer tes paramètres au lieu d'un objet (question stupide : les paramètres en question, c'est jamais des objets ? Ils sont pas instanciés à chaque fois ?)

Mais avant de faire tout ça, mesure. Il vaut mieux réaliser dès le début qu'instancier un Runnable pour chaque tâche, ne coûte rien, surtout comparé à tout ce qui est fait d'autre.

- 2 - les paramètres sont gérés en dehors de la classe,

Mais rien ne t'y oblige. C'est juste des exemples typiques.

[professeur shadoko]

euh ... est ce que déjà ceci te convient:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Commande implements Runnable {
    Object[] paramètres ; //ou autchose
    public Commande(Object... parms) {
          paramètres = parms ;
    }
    public void run() {
         / // joujou avec paramètres
    }
}

ensuite execute ou submit ou autre d'un objet Commande.

pourquoi regretter la création de chacun de ces objets?

[ToTo13]

Pourquoi faire ? C'est juste un objet. Ce n'est rien comparé au reste de la mécanique de soumission des tâches.

Si vraiment tu veux éviter ça, effectivement tu vas devoir te passer de ThreadPoolExecutor, et le recoder toi-même, avec un mécanisme pour passer tes paramètres au lieu d'un objet (question stupide : les paramètres en question, c'est jamais des objets ? Ils sont pas instanciés à chaque fois ?)

Mais avant de faire tout ça, mesure. Il vaut mieux réaliser dès le début qu'instancier un Runnable pour chaque tâche, ne coûte rien, surtout comparé à tout ce qui est fait d'autre.

Mais rien ne t'y oblige. C'est juste des exemples typiques.

Ben c'est bien ce qu'il me semblait. Dans mon cas le ThreadPoolExecutor n'est pas indiqué.

euh ... est ce que déjà ceci te convient:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Commande implements Runnable {
    Object[] paramètres ; //ou autchose
    public Commande(Object... parms) {
          paramètres = parms ;
    }
    public void run() {
         / // joujou avec paramètres
    }
}

ensuite execute ou submit ou autre d'un objet Commande.

pourquoi regretter la création de chacun de ces objets?

C'est quasiment la classe que j'ai déjà.

[professeur shadoko]

ça n'a rien à voir avec la question initiale mais tu dis que le calcul avec les paramètres est lourd.... y-a t'il des combinaisons de paramètres qui peuvent réapparaître?
est-il possible de faire un cache de résultats de calculs ou de calculs intermédiaires?

[ToTo13]

ça n'a rien à voir avec la question initiale mais tu dis que le calcul avec les paramètres est lourd.... y-a t'il des combinaisons de paramètres qui peuvent réapparaître?
est-il possible de faire un cache de résultats de calculs ou de calculs intermédiaires?

Non et non.
Tous les paramètres sont différents, ce qui m'oblige à manipuler à chaque itération un fichier plutôt lourd, c'est pour cela que je ne voulais pas traiter les paramètres avant l'appel et surtout ne pas ré-allouer.

[thelvin]

Ne pas réallouer des threads ça se comprend, mais des objets tout simples on peut se demander pourquoi. Tu manipules quoi, dans tes tâches, qui soit tellement plus rapide que créer un seul nouvel objet ?

[ToTo13]

Des fichiers tabulés de plusieurs dizaines voir centaines de Mo.
Et puis je suis absolument contre les ré-allocations évitable, donc inutiles.

[thelvin]

Des fichiers tabulés de plusieurs dizaines voir centaines de Mo.

Quel type de données ? Il doit bien y avoir masse objets là-dedans, non ?

Et puis je suis absolument contre les ré-allocations évitable, donc inutiles.

Mouais, mais Java ne va pas être ton ami, là-dessus.
Moi je mesure. Ça arrive parfois que limiter le nombre d'instanciations fasse gagner quelques pourcents, m'enfin, face à de la synchronisation multithreadée, c'est pas gagné cette histoire.

[ToTo13]

Quel type de données ? Il doit bien y avoir masse objets là-dedans, non ?

Ou pas :-(

Mouais, mais Java ne va pas être ton ami, là-dessus.
Moi je mesure. Ça arrive parfois que limiter le nombre d'instanciations fasse gagner quelques pourcents, m'enfin, face à de la synchronisation multithreadée, c'est pas gagné cette histoire.

Je fais du traitement d'images et de l'apprentissage/classement. Et je sens la différence produite par l'absence de ré-allocation systématique.


J'ai essayé le TPE pour mon problème (du coup en instanciant systématiquement à chaque appel) et j'ai une magnifique RejectedExecutionException :-(
Je vais rester sur une BlockingQueue qui me permet de faire ce que je veux sans rien ré-instancier et sans exception.

[thelvin]

Ou pas :-(

Je fais du traitement d'images et de l'apprentissage/classement. Et je sens la différence produite par l'absence de ré-allocation systématique.

Bon, c'est précisément le genre de cas où même en Java, on fera des pieds et des mains pour rien instancier dans la boucle -_-°.
Ici des pieds et des mains ça veut dire pas de TPE.

J'ai essayé le TPE pour mon problème (du coup en instanciant systématiquement à chaque appel) et j'ai une magnifique RejectedExecutionException :-(

Ça c'est parce que la queue était pleine. C'est un problème qui peut toujours arriver quand on cherche à faire faire des tâches par un pool de threads. 'Faut une plus grande queue, ou mettre en œuvre un moyen d'enregistrer les tâches à faire sur disque.

Je vais rester sur une BlockingQueue qui me permet de faire ce que je veux sans rien ré-instancier et sans exception.

Je commencerais par là, en effet. Mais bon, pas d'exception, ça veut dire soit que la queue était assez grande, soit que les threads attendent pour insérer dedans quand elle est pleine (ce qui risque de causer un deadlock,) soit que c'est une liste chaînée, avec donc instanciation d'un nœud à chaque nouvelle tâche.