Discussion :

[Brialex]

Bonjour,

Je suis en plein dev et j'aurai besoin de vos conseil. Je viens de termin? un programme qui fonctionne tres bien mais qui est aussi très long. Je souhaiterais don le faire ?voluer pour qu'il fonctionne en multithread(chose que je ne connais du tout).

Je cherche des exemples de code ou doc concernant le multithread et l'architecture du code a prevoir ?

Le but de mon programme est d'envoy? des infos au client et peux etre d?coup? en 3 ou 4 etapes :
- tester et valid? les commandes client.
-generer le doc associ?s
-generer le mail correspondant
-envoyer le tout au client.

L'idee serait de separer le code en 4 methodes differentes pour ensuite les executer de facon independantes.
La solution serait d'avoir un thread par methode mais je ne vois pas orchestrer le tout (mon client Dupond ne peux recevoir son mail tant que toute etapes ont ete faites).

Auriez vous des exemples de codes qui me permettrais d'avoir des explication sur les thread ?

Merci

[wallace1]

bonjour,

Il n existe pas d architecture de code generale a tout type de projet..... on parle de programmation pas de maconnerie !

Si tu n as pas un soupcon d idèe de depart ou d ebauche de code alors on ne te proposera rien d autres que des liens pour enrichir ta culture. Pour cela google est ton meilleur ami :

Thread vbnet

Thread C#

bonne lecture.

[ZenZiTone]

Le but de mon programme est d'envoy? des infos au client et peux etre d?coup? en 3 ou 4 etapes :
- tester et valid? les commandes client.
-generer le doc associ?s
-generer le mail correspondant
-envoyer le tout au client.

L'idee serait de separer le code en 4 methodes differentes pour ensuite les executer de facon independantes.
La solution serait d'avoir un thread par methode mais je ne vois pas orchestrer le tout (mon client Dupond ne peux recevoir son mail tant que toute etapes ont ete faites).

A première vue, l'utilisation des threads n'est pas la solution à ton problème. En effet, l'intérêt des threads est l'exécution simultanée de tâches. Hors, dans ton cas les étapes sont dépendantes les unes des autres, à l'exception de la génération des docs et mails.

As-tu identifié les parties du traitement qui étaient plus longues? Si oui, as tu essayer d'optimiser ton code dans un premier temps?

[sinople]

A première vue, l'utilisation des threads n'est pas la solution à ton problème. En effet, l'intérêt des threads est l'exécution simultanée de tâches. Hors, dans ton cas les étapes sont dépendantes les unes des autres, à l'exception de la génération des docs et mails.

Je vais faire mon chiant, mais non... Les thread ne s'exécutent jamais en simultané. Un processeur divise son temps "libre" sur plusieurs threads (il travail sur un truc, puis sur un autre et revient sur un truc après) ce qui permet d'éviter qu'une tâche "bloque" l'exécution d'une autre. Au final ça reste du séquentiel, même s'il est fractionnée en très petit morceau. A ne pas confondre avec l'exécution parallèle ou là effectivement on fait appel à plusieurs processeur de calcul qui travailleront en parallèle.

La on est plus dans de la distribution sur plusieurs serveur applicatif (même si tout ces serveurs sont hébergé dans une même application). Idéalement je regarderai du côté de WCF pour créer une architecture des services hébergé en interne sur l'application.

[Pol63]

je confirme que tu fais ton chiant ^^
que 2 threads ne s'exécutent jamais en simultané c'est partiellement vrai, mais techniquement seulement et encore ca doit pouvoir arriver (sur du multi coeur)
dans la pratique c'est comme ci
(et même sur un monocoeur sur un pc occupé, en mettant 2 threads à faire le même truc ca devrait aller plus vite car chaque thread aura le droit à autant de temps processeur, au détriment du reste en pourcentage)

rares sont les processeurs n'ayant qu'un cœur aujourd'hui, et si son programme tourne sur un serveur avec une ou deux dizaines de coeur il peut surement améliorer grandement le temps d'exécution
les étapes qu'il présente sont bien distinctes et ordonnées, mais rien ne semble empêcher de paralléliser au sein de chaque étape

[ZenZiTone]

Je vais faire mon chiant, mais non... Les thread ne s'exécutent jamais en simultané. Un processeur divise son temps "libre" sur plusieurs threads (il travail sur un truc, puis sur un autre et revient sur un truc après) ce qui permet d'éviter qu'une tâche "bloque" l'exécution d'une autre. Au final ça reste du séquentiel, même s'il est fractionnée en très petit morceau. A ne pas confondre avec l'exécution parallèle ou là effectivement on fait appel à plusieurs processeur de calcul qui travailleront en parallèle.

Certes, mais du point de vue applicatif, tu permets à deux séquences de s'exécuter simultanément. C'est virtuel, en effet, mais comme tu le dis : une séquence ne bloquera pas l'autre. Si mon "Thread1" se retrouve bloqué, mon "Thread2" continue à vivre sa vie

[sinople]

Bon mon interpellation avait surtout pour objectif de proposer de regarder sur les "concept" de niveau supérieur permettant de séparer et isoler le traitement de tâches complexe (Backgroundworker, WCF, Windows Workflow, Asynchrone, etc.) plutôt que de faire une nouvelle victime du InvokeRequired.