3 Thread dans une boucle for

bonjour

svp j'ai fait ce code

Code:

---

1 2 3 4 5 6 7

for(i=1;i<=3;i++) {     Thread t=new Thread()   }

---

Est ce que les 3 thread créé s'exécutent en parallèle ou non dans le boucle For

Si tu oublie le start déjà sa peut pas marcher :)

Code:

---

1 2	Thread t = new Thread(); t.start();

---

Sinon tu peut essayer

Code:

---

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

public class MyThread extends Thread{   public static void main (String[] args){   for(int i=0;i<3;i++){ Thread t = new MyThread(); t.start(); } } @Override public void run(){ System.out.println(System.currentTimeMillis()); }   }

---

Tu verra que les trois Threads affiche le même temps en milisecondes

Citation:

---

Envoyé par maxime8n

Si tu oublie le start déjà sa peut pas marcher :)

Code:

---

1 2	Thread t = new Thread(); t.start();

---

---

Certes.

Citation:

---

Envoyé par maxime8n

Sinon tu peut essayer

Code:

---

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

public class MyThread extends Thread{   public static void main (String[] args){   for(int i=0;i<3;i++){ Thread t = new MyThread(); t.start(); } } @Override public void run(){ System.out.println(System.currentTimeMillis()); }   }

---

Tu verra que les trois Threads affiche le même temps en milisecondes

---

Euh. Et alors ?


Pour répondre à la question : oui, des Threads ça s'exécute en parallèle. C'est à ça que ça sert. On a pas de raison d'aller chercher des Thread, si ce n'est pas pour que ça s'exécute en parallèle.

Citation:

---

Envoyé par thelvin

Euh. Et alors ?.

---

Bah tu vois que les trois threads on démarré en même temps :)

Citation:

---

Envoyé par maxime8n

Bah tu vois que les trois threads on démarré en même temps :)

---

Non. Ils ont démarré l'un après l'autre, mais à très peu de temps d'intervalle.

On ferait trois fois System.out.println(System.currentTimeMillis()); sans aucun thread, ça ferait pareil.
En principe ils sont séparés par un peu plus de temps, parce que là on se tape des IO bloquantes en séquence, alors que les threads, justement, passent la main à d'autres threads quand ils tombent sur une IO bloquante, ce qui fait que les threads ne font qu'appeler trois fois System.currentTimeMillis() et ensuite seulement affichent leurs résultats.
Ça augmente les chances d'avoir peu de temps de différence, mais ça ne garantit pas d'en avoir moins qu'avec une approche en séquence.

merci beaucoup :)

donc lorsque je mets beaucoup de Thread: plus que 20 Thread dans un boucle FOR il n'est pas garantit d'optimiser le temps d’exécution ( c'est mon but )

Citation:

---

Envoyé par Etudiante_Ines

donc lorsque je mets beaucoup de Thread: plus que 20 Thread dans un boucle FOR il n'est pas garantit d'optimiser le temps d’exécution ( c'est mon but )

---

Bien sûr que non.

- D'abord parce que dans tes exemples les threads font des trucs très courts, et que juste créer les threads, les démarrer et attendre qu'ils aient fini, est plus long que le travail lui-même.

- Ensuite parce que tu n'as certainement pas 20 cœurs de processeur pour paralléliser tout ça, et que les threads ne passent pas forcément leur temps dans des IO bloquantes.

=> Si les threads amélioraient toujours les performances, on aurait pas besoin de les programmer. Java ferait des threads partout sans qu'on lui demande, afin d'avoir les meilleures performances.

Code:

---

1 2 3 4

for(int i=0;i<3;i++){ Thread t = new MyThread(); t.start(); }

---

Je ne comprend pas l'utilité de t :

Code:

---

1 2	for(int i=0;i<3;i++) new MyThread().start();

---

est plus simple et plus efficace.

donc c'est quoi la solution ??? je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle :?

Citation:

---

Envoyé par Etudiante_Ines

donc c'est quoi la solution ???

---

Qu'est-ce qui te fait penser qu'il y en a une ? De toute façon, que ça soit le cas ou non, on va pas deviner...

Citation:

---

Envoyé par Etudiante_Ines

je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes

---

C'est assez vague, quand même.

Citation:

---

Envoyé par Etudiante_Ines

et je veux qu'ils s’exécutent en parallèle :?

---

Peut-être pas toutes en parallèles ? Un truc comme par exemple 3 threads qui se partagent les 20 travaux à faire ?
S'il n'y a pas d'IO, et si le traitement n'est pas complètement immédiat, on aime bien N threads ou N+1 threads, avec N le nombre de cœurs disponibles. Comme on ne sait pas à l'avance le nombre de cœurs disponibles, on pourrait par exemple se caler sur 5 threads.

Mais si le traitement est immédiat et qu'il n'y a pas d'IO, les faire en parallèle, ça n'optimise rien du tout, bien au contraire.

Citation:

---

Envoyé par Etudiante_Ines

je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle :?

---

Il ne faut pas oublier que lorsqu'on utilise des threads, la JVM est obligée de gérer leur ordonnancement. Donc ce n'est pas toujours interessant d'en utiliser. Dans ton cas, qu'est ce qui te fait penser qu'utiliser des threads ameliorerait les performances ?
Elles font quoi ces regles ?

se sont des règles SWRL ( je suis débutante dans le domaine des webs semantiques, ontologie, regles swrl ) mais maintenant je fais la tache : optimiser le temps de matching entre ces règles sachant qu'il y a plus que 20 règles indépendantes

Oui mais, on va pas faire ton boulot, et en ce qui me concerne je ne sais pas ce que c'est, du matching de règles SWRL. Et ça ne m'intéresse pas de le savoir non plus, c'est ton travail.

Puisque quelqu'un te demande de l'optimiser, et qu'elles sont indépendantes, alors on peut supposer que le calcul n'est pas immédiat, qu'il est parallélisable, et que c'est intéressant de le paralléliser.

S'il n'y a pas d'IO en jeu, et on peut supposer qu'il n'y en a pas, l'approche est de créer quelques threads, quelques, un nombre relativement petit, et qu'ils se partagent le travail à faire : chaque thread prend un travail dans la pile de travaux à faire, et le fait. Quand il a terminé, il en prend un autre, et ainsi de suite.
On appelle ça un pool de threads.
L'intérêt est d'en avoir plusieurs pour paralléliser le travail, mais de ne pas en avoir trop. En avoir trop ferait passer plus de temps à gérer les threads qu'à les exécuter.

Le plus simple pour cela est d'utiliser ThreadPoolExecutor.

Dans l'absolu, si on soupconne que c'est optimisable par multi threading, faire le code de multithreading, puis faire des mesures et regarder.

Si chaque règle prend plusieurs secondes -> oui tu risque d'y gagner
Si chaque règle est rapide mais qu'on fait 50.000 demande de comparaison pas seconde -> non tu va rien y gagner.

Citation:

---

Envoyé par Etudiante_Ines

donc c'est quoi la solution ??? je veux optimiser le temps d’exécution du code sachant que j'ai plus que 20 règles indépendantes et je veux qu'ils s’exécutent en parallèle :?

---

Pourquoi ne pas envisager Observer/Observable, les règles ne seront pas appliquées en parallèles mais simultanément en time sharing, c'est Java qui gère/optimise les threads.
Ce Pattern Observateur est très souple. Il est tout à fait adapté pour l'application de règles indépendantes.
Sinon il faut voir les outils de parallélisation.

Par défaut ce patter n'a rien de multithreadé. De plus je vois pas le rapport entre une observation de changement d'état (pattern observer) et ce que veux faire la personne ici: un algorithme de validation multi règles.

Pas si simple : dans la documentation Observable.html

La conclusion :
Note that this notification mechanism is has nothing to do with threads and is completely separate from the wait and notify mechanism of class Object.

et un peu avant :
The order in which notifications will be delivered is unspecified. The default implementation provided in the Observable class will notify Observers in the order in which they registered interest,but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or may guarantee that their subclass follows this order, as they choose.

L'optimisation les utilise au mieux.

Donc si l'objet est en Observable et que chaque règles a son Observer, cela devrait convenir,
Changer l'objet observé + setChanged() + notifyObservers() lance l'application/l'exécution simultanée des vingt règles sélectionnées

Oui, c'est possible d'utiliser les Observable en contexte multithreadé, à condition de se taper tout le boulot soi-même, mais en quoi ça aide à faire du multithreadé ?
En quoi le pattern observateur aide-t-il à faire quoi que ce soit dans la question ?

Citation:

---

Envoyé par thelvin

Oui, c'est possible d'utiliser les Observable en contexte multithreadé, à condition de se taper tout le boulot soi-même, mais en quoi ça aide à faire du multithreadé ?
En quoi le pattern observateur aide-t-il à faire quoi que ce soit dans la question ?

---

C'est à Etudiante_Ines de voir selon son problème réel :
le Pattern Observateur répond-il au besoin ou non ? (Si Java n'a pas voulu utiliser des threads 'visibles' et laisse le compilateur générer et gérer ceux qui sont nécessaires, ce n'est sûrement pas gratuit)

Sinon qu'elle précise sa demande

Citation:

---

Envoyé par cylere

C'est à Etudiante_Ines de voir selon son problème réel :
le Pattern Observateur répond-il au besoin ou non ?

---

... Je reconnais que c'est pas totalement impossible, mais il me semble qu'il y aurait eu, je sais pas, n'importe quoi d'autre de plus pertinent, à aborder d'abord, non ?

Citation:

---

Envoyé par cylere

(Si Java n'a pas voulu utiliser des threads 'visibles' et laisse le compilateur générer et gérer ceux qui sont nécessaires,[...])

---

... Ok, j'ai aucune idée de ce que tu as en tête.

Citation:

---

Envoyé par thelvin

... Je reconnais que c'est pas totalement impossible, mais il me semble qu'il y aurait eu, je sais pas, n'importe quoi d'autre de plus pertinent, à aborder d'abord, non ?

---

J'ai pensé à Jade Java échange entre agents http://djug.developpez.com/java/jade/creation-agent/ : faire une sorte de grid avec chaque PC du cours comme agent (gestionnaire d'une règles) déclenché par message, mais pour un étudiant débutant ...

Citation:

---

Envoyé par thelvin

... Ok, j'ai aucune idée de ce que tu as en tête.

---

Avec l'age le vide remplace l'égo, ... et c'est bien plus amusant. :D

Citation:

---

Envoyé par cylere

L'optimisation les utilise au mieux.

---

Je crois que tu imagine que magiquement la JVM utilsie des threads quand c'est éncessaire, mais c'est faut. Comme dit Elvin, c'est à toi de te tapper tout le boulot! On est complètement à coté de la plaque par rapport au besoin.

Le besoin est d'optimiser des règles, et de voir si c'est intéressant en multithread. Poru ça il y a des truc comme le ThreadPoolExecutor qui peuvent éventuellement servir, mais je commencerais par une implémentation plancher de type new MyThread(reglesAtester[i],donnee).start() et puis seulement on cherchera plus efficace. Si ça montre une perte de perf, c'est pas la peine selon moi d'aller plus en avant.

En fait, je ne vois pas où on va regagner le temps perdu par le multi-threading, mais il est vrai qu'on n'a qu'une vague idée ce qui doit être fait...

Citation:

---

Envoyé par tchize_

Je crois que tu imagine que magiquement la JVM utilsie des threads quand c'est éncessaire, mais c'est faut. Comme dit Elvin, c'est à toi de te tapper tout le boulot! On est complètement à coté de la plaque par rapport au besoin.

---

Désolé, mais rappel à la nétiquette, non pour les fautes d'orthographes et la formulation surprenante de la part d'un modérateur, mais surtout pour une lecture partielle et une réponse fébrile avec fixation et mise en avant de sa solution.

Ceci est d'autant plus grave que ceux qui auraient envie de partager leur expérience, de proposer des solutions innovantes ou de confronter leurs interrogations vont voir ailleurs, je citerais stackexchange.com comme référence.

Citation:

---

Envoyé par BenWillard

En fait, je ne vois pas où on va regagner le temps perdu par le multi-threading, mais il est vrai qu'on n'a qu'une vague idée ce qui doit être fait...

---

Merci de cette remarque.
En effet, j'ai répondu sur cette discussion en ayant en tête le question précédente posée par Etudiante_Ines, et comme les Méthodes Agiles préconisent de ne pas faire ce qui n'est pas nécessaire ... se poser les bonnes questions et utiliser les objets validés fait partie de la bonne programmation

Il n'y a plus qu'a attendre

Le plus simple c'est encore un pool de Thread, puis des tests de perfs pour voir le nombre de Thread optimal à avoir.

cylere, c'est bien de proposer des solutions originale, mais on répond ici à une personne débutante. Inutile donc de lui farcir ses réponses de concept qui risque de l'embrouiller. Si tu souhaites parler de solutions innovantes, il serait bien plus efficient d'ouvrir un sujet dans la catégorie adéquate et de lancer la discussion.

Citation:

---

Envoyé par deathness

cylere, c'est bien de proposer des solutions originale, mais on répond ici à une personne débutante. Inutile donc de lui farcir ses réponses de concept qui risque de l'embrouiller. Si tu souhaites parler de solutions innovantes, il serait bien plus efficient d'ouvrir un sujet dans la catégorie adéquate et de lancer la discussion.

---

Vous avez pu remarquer que j'avais pris en compte la situation personnelle dans un précédent post.

Java n'est pas qu'un problème de codification, et les Pattern Designs représentent un somme d'expériences à ne pas refaire.
De plus il font partie du cursus minimal obligatoire de l'apprentissage des langages objets.

Ayant toujours une soif de connaître inextinguible, je reste encore suffisamment naïf et optimiste pour espérer n'être pas le seul dans ce cas.

Attendons donc la réponse

Citation:

---

Envoyé par cylere

Vous avez pu remarquer que j'avais pris en compte la situation personnelle dans un précédent post.

Java n'est pas qu'un problème de codification, et les Pattern Designs représentent un somme d'expériences à ne pas refaire.
De plus il font partie du cursus minimal obligatoire de l'apprentissage des langages objets.

Ayant toujours une soif de connaître inextinguible, je reste encore suffisamment naïf et optimiste pour espérer n'être pas le seul dans ce cas.

---

De là à proposer directement des design patterns très avancés et au rapport très distants à la question posée... Déjà que mon pattern executor, un peu plus à propos, je le trouvais limite...

Citation:

---

Envoyé par cylere

Attendons donc la réponse

---

Oui ben ça va se faire attendre un moment si la personne doit apprendre la théorie des multi agents sans avoir la moindre idée du rapport avec la question posée, avant de venir donner une réponse.

Nan mais euh, c'est quoi la question ? Soit je n'ai rien compris, soit... euh ... je ne comprend pas :mouarf:

Citation:

---

Est ce que les 3 thread créé s'exécutent en parallèle ou non dans le boucle For

---

Réponse : "oui". Sujet clos :)

Citation:

---

Java n'est pas qu'un problème de codification, et les Pattern Designs représentent un somme d'expériences à ne pas refaire.

---

Certes, mais pour comprendre l'intérêt des DP, il faut refaire quelques expériences... "Java n'est pas qu'un problème de codification", en effet, ce n'est pas que ça, mais c'est ça aussi.